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
<[email protected] <mailto:[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] <mailto:sip%[email protected]>
to_uri:: sip:[email protected]
<mailto:sip%[email protected]>
caller_tag:: 1i4vfmjico
caller_contact:: sip:[email protected]
<mailto:sip%[email protected]>: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@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] <mailto:sip%[email protected]>
to_uri:: sip:[email protected]
<mailto:sip%[email protected]>
caller_tag:: 1i4vfmjico
caller_contact:: sip:[email protected]
<mailto:sip%[email protected]>: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 <[email protected]
<mailto:[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] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_______________________________________________
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
