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 < [email protected]> 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@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:[email protected] > to_uri:: sip:[email protected] > caller_tag:: 1i4vfmjico > caller_contact:: sip:[email protected]: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@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:[email protected] > to_uri:: sip:[email protected] > caller_tag:: 1i4vfmjico > caller_contact:: sip:[email protected]: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 <[email protected]> > 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 >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> -- >> Răzvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
