[OpenSIPS-Users] Proto WSS No Open TCP Connection after reinvite
Sebastian Sastre
sastre.sebastian at gmail.com
Mon Jul 23 11:43:00 EDT 2018
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> 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
> to_uri:: sip:18889990000 at domain.com
> caller_tag:: 1i4vfmjico
> caller_contact:: sip:lccpphv2 at 192.168.202.3:51292;transport=wss;ob
> callee_cseq:: 0
> caller_route_set::
> caller_bind_addr:: wss:10.101.10.151:443
> caller_sdp::
> CALLEES::
> callee::
> callee_tag:: d651df12-c9c2-4db1-99ad-b15d6240ffee
> callee_contact:: sip:10.101.10.161:5060
> caller_cseq:: 1094
> callee_route_set::
> callee_bind_addr:: udp: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
> to_uri:: sip:18889990000 at domain.com
> caller_tag:: 1i4vfmjico
> caller_contact:: sip:lccpphv2 at 192.168.202.3:51292;transport=wss;ob
> callee_cseq:: 0
> caller_route_set::
> caller_bind_addr:: wss:10.101.10.151:443
> caller_sdp::
> CALLEES::
> callee::
> callee_tag:: d651df12-c9c2-4db1-99ad-b15d6240ffee
> callee_contact:: sip:10.101.10.161:5060
> caller_cseq:: 1095
> callee_route_set::
> callee_bind_addr:: udp:10.101.10.151:5060
> callee_sdp::
>
>
> On Mon, Jul 16, 2018 at 7:55 AM, Răzvan Crainea <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
>>> 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/20180723/9bdcaabf/attachment.html>
More information about the Users
mailing list