[OpenSIPS-Users] Proto WSS No Open TCP Connection after reinvite
Sebastian Sastre
sastre.sebastian at gmail.com
Thu Aug 2 09:27:39 EDT 2018
Hey guys, sorry to keep insisting, im just very curious why its not finding
that TCP connection.
Nothing anywhere tells or yields an error.
What else can I look at?
On Mon, Jul 23, 2018 at 11:58 AM, Sebastian Sastre <
sastre.sebastian at gmail.com> wrote:
> I put a full debug on this paste https://pastebin.com/BEJ6fAR8
>
> Should be
>
> Jul 13 11:42:39 gcwregistrar151 /sbin/opensips[3647]: ERROR:tm:msg_send:
> send() to 192.0.2.246:443 for proto wss/6 failed
>
> Thanks
>
>
> On Mon, Jul 23, 2018 at 11:47 AM, Răzvan Crainea <razvan at opensips.org>
> wrote:
>
>> Hi, Sebastien!
>>
>> It looks like the contact is not changing. Can you indicate what
>> connection he is trying to find, i.e. what IP, port and proto? You should
>> see them in the error line.
>>
>> Best regards,
>> Răzvan
>>
>> On 07/23/2018 06:43 PM, Sebastian Sastre wrote:
>>
>>> Hey Razvan,
>>>
>>> I’ve been playing around a lot with this but I can’t seem to make it
>>> work. Whatever I do without the fix route doesn’t find a suitable tcp
>>> connection.
>>>
>>> Do you see something on the dlg_list before that would indicate the
>>> problem Or is there any other debug I can use ?
>>>
>>> Thanks again !
>>>
>>>
>>> On Thu, Jul 19, 2018 at 8:03 PM, Sebastian Sastre <
>>> sastre.sebastian at gmail.com <mailto:sastre.sebastian at gmail.com>> wrote:
>>>
>>> Razvan,
>>> Thanks ! I tried what you indicated but I don’t see the contact
>>> changing. Im taking care of the fix contacts where it needs to be
>>> bet but still on the bye it can’t find it.
>>>
>>>
>>> root at gcwregistrar151:~$ opensipsctl fifo dlg_list. *(Call
>>> Connected)*
>>> dialog:: ID=5820137817639
>>> state:: 4
>>> user_flags:: 0
>>> timestart:: 1532043804
>>> datestart:: 2018-07-19 19:43:24
>>> timeout:: 1532044163
>>> dateout:: 2018-07-19 19:49:23
>>> callid:: fp436dll6pcmdqk78gn6
>>> from_uri:: sip:user at domain.com <mailto:
>>> sip%3Auser at domain.com>
>>> to_uri:: sip:18889990000 at domain.com
>>> <mailto:sip%3A18889990000 at domain.com>
>>> caller_tag:: 1i4vfmjico
>>> caller_contact:: sip:lccpphv2 at 192.168.202.3
>>> <mailto:sip%3Alccpphv2 at 192.168.202.3>:51292;transport=wss;ob
>>> callee_cseq:: 0
>>> caller_route_set::
>>> caller_bind_addr:: wss:10.101.10.151:443
>>> <http://10.101.10.151:443>
>>> caller_sdp::
>>> CALLEES::
>>> callee::
>>> callee_tag::
>>> d651df12-c9c2-4db1-99ad-b15d6240ffee
>>> callee_contact:: sip:10.101.10.161:5060
>>> <http://10.101.10.161:5060>
>>> caller_cseq:: 1094
>>> callee_route_set::
>>> callee_bind_addr:: udp:10.101.10.151:5060
>>> <http://10.101.10.151:5060>
>>> callee_sdp::
>>>
>>> root at gcwregistrar151:~$ opensipsctl fifo dlg_list *(Call on Hold )*
>>> dialog:: ID=5820137817639
>>> state:: 4
>>> user_flags:: 0
>>> timestart:: 1532043804
>>> datestart:: 2018-07-19 19:43:24
>>> timeout:: 1532044163
>>> dateout:: 2018-07-19 19:49:23
>>> callid:: fp436dll6pcmdqk78gn6
>>> from_uri:: sip:user at domain.com <mailto:
>>> sip%3Auser at domain.com>
>>> to_uri:: sip:18889990000 at domain.com
>>> <mailto:sip%3A18889990000 at domain.com>
>>> caller_tag:: 1i4vfmjico
>>> caller_contact:: sip:lccpphv2 at 192.168.202.3
>>> <mailto:sip%3Alccpphv2 at 192.168.202.3>:51292;transport=wss;ob
>>> callee_cseq:: 0
>>> caller_route_set::
>>> caller_bind_addr:: wss:10.101.10.151:443
>>> <http://10.101.10.151:443>
>>> caller_sdp::
>>> CALLEES::
>>> callee::
>>> callee_tag::
>>> d651df12-c9c2-4db1-99ad-b15d6240ffee
>>> callee_contact:: sip:10.101.10.161:5060
>>> <http://10.101.10.161:5060>
>>> caller_cseq:: 1095
>>> callee_route_set::
>>> callee_bind_addr:: udp:10.101.10.151:5060
>>> <http://10.101.10.151:5060>
>>> callee_sdp::
>>>
>>>
>>> On Mon, Jul 16, 2018 at 7:55 AM, Răzvan Crainea <razvan at opensips.org
>>> <mailto:razvan at opensips.org>> wrote:
>>>
>>> Hi, Sebastian!
>>>
>>> The re-invite probably generates a remote contact update. And if
>>> you don't "fix" the contact on re-invites and their 200 OK, you
>>> might end up with broken contacts in the dialog, thus sequential
>>> signaling will not work.
>>> I suggest you do two things to debug this:
>>> 1. remove the fix_route_dialog() call - the call should still be
>>> routed according to RR information, presuming this information
>>> is correct.
>>> 2. start the call, run `opensipsctl fifo dlg_list` and write
>>> down the WSS's contact, then put the call on hold, and check
>>> again the contact.
>>>
>>> Best regards,
>>> Răzvan
>>>
>>>
>>> On 07/13/2018 09:19 PM, Sebastian Sastre wrote:
>>>
>>>
>>> Hello, I’ve been experiencing a situation with Proto WSS.
>>> The scenario is very simple. A call is established from an
>>> Asterisk Box to Opensips (UDP) and finally a SipJs7.8 (WSS).
>>> Everything works great and we are able to register using mid
>>> registrar and pass calls thru.
>>>
>>> When an agent puts the call on hold a reinvite is correctly
>>> negotiated and the call is placed on hold and viceversa.
>>> However!, if the originating caller disconnects the call
>>> while still on hold, Asterisk will correctly terminate the
>>> dialog with a Bye but when OpenSIPs will complain about not
>>> finding a suitable tcp connection and responds with a 477
>>> even after successfully matching and processing the dialog
>>> termination correctly.
>>>
>>> opensipsctl fifo list_tcp_conns shows the connection
>>> available.
>>>
>>> The only way I found of fixing this problem is by adding
>>> fix_route_dialog() on the sequential loose route.
>>>
>>> if (loose_route()) {
>>> if (is_method("BYE")) {
>>> if (!validate_dialog()){
>>> fix_route_dialog();
>>> }
>>>
>>> What do you guys think?
>>> Am I messing up something in the script or is this the
>>> correct way to address this problem?
>>>
>>> The funny thing is that there is no difference notable
>>> between the bye after hold and a regular bye without putting
>>> the call on hold.
>>> Here is the opensips log with the error and the trace.
>>>
>>> https://pastebin.com/BEJ6fAR8
>>>
>>> Thanks !
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>>
>>>
>>> -- Răzvan Crainea
>>> OpenSIPS Core Developer
>>> http://www.opensips-solutions.com
>>> <http://www.opensips-solutions.com>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>> --
>> Răzvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.com
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180802/0061ddc4/attachment-0001.html>
More information about the Users
mailing list