[OpenSIPS-Users] Proto WSS No Open TCP Connection after reinvite
Răzvan Crainea
razvan at opensips.org
Mon Jul 23 11:47:37 EDT 2018
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
More information about the Users
mailing list