Missing Route headers in locally generated BYE
Hi, I locally generate BYE using dlg_end_dlg. When I want to end a call that is "transport layer" bridged, the BYE is not sent to first hop in route_set but directly to the endpoint. In such BYE there are no Route headers. In non-bridging calls Routes are correctly placed and the message is routed to the first "hop". When the error happens, this is written to a log: WARNING: rr [loose.c:821]: after_loose(): no socket found for match second RR Here ([SR-Users] no socket found for match second RR) I have read this is only a warning, but in my configuration it seriously influences the message routing. My setup is phone1(192.168.10.3) <--TCP--> kamailio1(192.168.10.2) <--UDP--> kamailio2(192.168.5.3) <--UDP--> phone2 On kamailio1 I generate dlg_end_dlg and the BYE is sent to phone1 and phone2 directly. I'm using Kamailio 4.0.4 on Debian machines. How can I make the Kamailio1 to send the BYE to kamailio2 in the transport layer bridging scenario? Do I have some misconfiguration or this is not a correct behaviour? Thanks for answer Efelin
Hello, can you share the database record or kamctl mi dlg_list for such call? It helps to see if record route values are stored properly in first place. Cheers, Daniel On 05/12/13 14:47, Efelin Novak wrote:
Hi,
I locally generate BYE using dlg_end_dlg. When I want to end a call that is "transport layer" bridged, the BYE is not sent to first hop in route_set but directly to the endpoint. In such BYE there are no Route headers. In non-bridging calls Routes are correctly placed and the message is routed to the first "hop".
When the error happens, this is written to a log:
WARNING: rr [loose.c:821]: after_loose(): no socket found for match second RR
Here ([SR-Users] no socket found for match second RR) I have read this is only a warning, but in my configuration it seriously influences the message routing.
My setup is
phone1(192.168.10.3) <--TCP--> kamailio1(192.168.10.2) <--UDP--> kamailio2(192.168.5.3) <--UDP--> phone2
On kamailio1 I generate dlg_end_dlg and the BYE is sent to phone1 and phone2 directly.
I'm using Kamailio 4.0.4 on Debian machines.
How can I make the Kamailio1 to send the BYE to kamailio2 in the transport layer bridging scenario? Do I have some misconfiguration or this is not a correct behaviour?
Thanks for answer
Efelin
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
I just tested this with dialog timeout and can confirm that there are no Route headers in the locally generated BYEs. The Record-Route set for the dialog is: Record-Route: <sip:172.30.105.18;lr=on;ftag=ervXH3ycHcgpK;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA--;proxy_media=yes;dlgcor=fa8.9ea> The BYEs from Kamailio don't have a Route header at all. Just these: 03:27:37.464071 IP 172.30.105.18.5060 > 172.30.105.20.5060: SIP, length: 367 E.......@._'.4..?..U.....w^.BYE sip:mod_sofia@172.30.105.20:5060 SIP/2.0 Via: SIP/2.0/UDP 172.30.105.18;branch=z9hG4bK6e86.3c0a9a04000000000000000000000000.0 To: <sip:6785551212@172.30.105.20>;tag=ervXH3ycHcgpK From: <sip:4045551212@172.30.105.18>;tag=SD7hk6c99-ac3f4687+1+337b0015+5485357b CSeq: 1 BYE Call-ID: 34fdb244-dce1-1231-ee8e-00163e6490b7 Content-Length: 0 Max-Forwards: 70 Of course, that doesn't stop them from working. -- Alex On 12/11/2013 02:50 AM, Daniel-Constantin Mierla wrote:
Hello,
can you share the database record or kamctl mi dlg_list for such call? It helps to see if record route values are stored properly in first place.
Cheers, Daniel
On 05/12/13 14:47, Efelin Novak wrote:
Hi,
I locally generate BYE using dlg_end_dlg. When I want to end a call that is "transport layer" bridged, the BYE is not sent to first hop in route_set but directly to the endpoint. In such BYE there are no Route headers. In non-bridging calls Routes are correctly placed and the message is routed to the first "hop".
When the error happens, this is written to a log:
WARNING: rr [loose.c:821]: after_loose(): no socket found for match second RR
Here ([SR-Users] no socket found for match second RR) I have read this is only a warning, but in my configuration it seriously influences the message routing.
My setup is
phone1(192.168.10.3) <--TCP--> kamailio1(192.168.10.2) <--UDP--> kamailio2(192.168.5.3) <--UDP--> phone2
On kamailio1 I generate dlg_end_dlg and the BYE is sent to phone1 and phone2 directly.
I'm using Kamailio 4.0.4 on Debian machines.
How can I make the Kamailio1 to send the BYE to kamailio2 in the transport layer bridging scenario? Do I have some misconfiguration or this is not a correct behaviour?
Thanks for answer
Efelin
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Hi, why should Kamailio add a route for himself to an outbound request? 172.30.105.18 is obviously the proxy itself; so adding the Route-Header makes no sense.... (at least from a SIP-Perspective). Record-Route: <sip:172.30.105.18;lr=on;ftag=ervXH3ycHcgpK;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA--;proxy_media=yes;dlgcor=fa8.9ea> 03:27:37.464071 IP 172.30.105.18.5060 > 172.30.105.20.5060: SIP, length: 367 Or am i missing something here? Kind regards, Carsten 2013/12/11 Alex Balashov <abalashov@evaristesys.com>:
I just tested this with dialog timeout and can confirm that there are no Route headers in the locally generated BYEs.
The Record-Route set for the dialog is:
Record-Route: <sip:172.30.105.18;lr=on;ftag=ervXH3ycHcgpK;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA--;proxy_media=yes;dlgcor=fa8.9ea>
The BYEs from Kamailio don't have a Route header at all. Just these:
03:27:37.464071 IP 172.30.105.18.5060 > 172.30.105.20.5060: SIP, length: 367 E.......@._'.4..?..U.....w^.BYE sip:mod_sofia@172.30.105.20:5060 SIP/2.0 Via: SIP/2.0/UDP 172.30.105.18;branch=z9hG4bK6e86.3c0a9a04000000000000000000000000.0 To: <sip:6785551212@172.30.105.20>;tag=ervXH3ycHcgpK From: <sip:4045551212@172.30.105.18>;tag=SD7hk6c99-ac3f4687+1+337b0015+5485357b CSeq: 1 BYE Call-ID: 34fdb244-dce1-1231-ee8e-00163e6490b7 Content-Length: 0 Max-Forwards: 70
Of course, that doesn't stop them from working.
-- Alex
On 12/11/2013 02:50 AM, Daniel-Constantin Mierla wrote:
Hello,
can you share the database record or kamctl mi dlg_list for such call? It helps to see if record route values are stored properly in first place.
Cheers, Daniel
On 05/12/13 14:47, Efelin Novak wrote:
Hi,
I locally generate BYE using dlg_end_dlg. When I want to end a call that is "transport layer" bridged, the BYE is not sent to first hop in route_set but directly to the endpoint. In such BYE there are no Route headers. In non-bridging calls Routes are correctly placed and the message is routed to the first "hop".
When the error happens, this is written to a log:
WARNING: rr [loose.c:821]: after_loose(): no socket found for match second RR
Here ([SR-Users] no socket found for match second RR) I have read this is only a warning, but in my configuration it seriously influences the message routing.
My setup is
phone1(192.168.10.3) <--TCP--> kamailio1(192.168.10.2) <--UDP--> kamailio2(192.168.5.3) <--UDP--> phone2
On kamailio1 I generate dlg_end_dlg and the BYE is sent to phone1 and phone2 directly.
I'm using Kamailio 4.0.4 on Debian machines.
How can I make the Kamailio1 to send the BYE to kamailio2 in the transport layer bridging scenario? Do I have some misconfiguration or this is not a correct behaviour?
Thanks for answer
Efelin
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Carsten Bock CEO (Geschäftsführer) ng-voice GmbH Schomburgstr. 80 D-22767 Hamburg / Germany http://www.ng-voice.com mailto:carsten@ng-voice.com Office +49 40 34927219 Fax +49 40 34927220 Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284 Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/
Carsten, On 12/11/2013 03:36 AM, Carsten Bock wrote:
why should Kamailio add a route for himself to an outbound request? 172.30.105.18 is obviously the proxy itself; so adding the Route-Header makes no sense.... (at least from a SIP-Perspective).
Record-Route: <sip:172.30.105.18;lr=on;ftag=ervXH3ycHcgpK;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA--;proxy_media=yes;dlgcor=fa8.9ea>
03:27:37.464071 IP 172.30.105.18.5060 > 172.30.105.20.5060: SIP, length: 367
Or am i missing something here?
That depends, philosophically, on whether the intention of this feature is to spoof BYEs so that they appear to come from the respective UAs toward each other through the proxy (or, in substance, act as if they were), or for Kamailio to unexpectedly take on the role of a UAC mid-call. :-) -- Alex -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Hello, On 11/12/13 09:38, Alex Balashov wrote:
Carsten,
On 12/11/2013 03:36 AM, Carsten Bock wrote:
why should Kamailio add a route for himself to an outbound request? 172.30.105.18 is obviously the proxy itself; so adding the Route-Header makes no sense.... (at least from a SIP-Perspective).
Record-Route: <sip:172.30.105.18;lr=on;ftag=ervXH3ycHcgpK;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA--;proxy_media=yes;dlgcor=fa8.9ea>
03:27:37.464071 IP 172.30.105.18.5060 > 172.30.105.20.5060: SIP, length: 367
Or am i missing something here?
That depends, philosophically, on whether the intention of this feature is to spoof BYEs so that they appear to come from the respective UAs toward each other through the proxy (or, in substance, act as if they were), or for Kamailio to unexpectedly take on the role of a UAC mid-call. :-) there must not be any route for proxy itself, even when BYE is sent by end UA the Route is consumed by proxy, so it is no difference from this perspective.
In the initial email on this thread, there was a second proxy, so I wanted to see the route header stored for that proxy. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On 12/11/2013 03:41 AM, Daniel-Constantin Mierla wrote:
there must not be any route for proxy itself, even when BYE is sent by end UA the Route is consumed by proxy, so it is no difference from this perspective.
Oh, yeah. [slaps head] That's true. You and Carsten are correct. -- Alex -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Hi Daniel, thanks for an answer & sorry for the delay (Christmas time). Here we go: Scenario: phone1(192.168.9.3, 192.168.10.75 (nat)) <--TCP--> kamailio1(192.168.10.2) <--UDP--> kamailio2(192.168.5.3) <--UDP--> phone2(192.168.12.2) dialog:: hash=1456:1090244220 state:: 4 timestart:: 1388767148 timeout:: 111170022 callid:: 7fbca98b-22ea049@192.168.9.3 from_uri:: sip:phone1@example.com from_tag:: 17cfe8a323b2ac11o1 caller_contact:: sip:phone1@192.168.10.75:5075;transport=tcp caller_cseq:: 102 caller_route_set:: caller_bind_addr:: tcp:192.168.10.2:5060 to_uri:: sip:phone2@example.com to_tag:: a94c095b773be1dd6e8d668a785a9c84ec059e7d callee_contact:: sip:phone2@192.168.12.2:5060 callee_cseq:: 102 callee_route_set:: <sip:192.168.10.2;r2=on;lr=on;ftag=17cfe8a323b2ac11o1;vsf=AAAAAAAGAQIIAAIDAgh5UEBXIR0VSRIfZS5zaw--;nat=yes;did=0b5.c7ecbf04>,<sip:192.168.5.3;lr=on;did=0b5.0b> callee_bind_addr:: udp:192.168.10.2:5060 Efelin 2013/12/11 Alex Balashov <abalashov@evaristesys.com>
On 12/11/2013 03:41 AM, Daniel-Constantin Mierla wrote:
there must not be any route for proxy itself, even when BYE is sent by
end UA the Route is consumed by proxy, so it is no difference from this perspective.
Oh, yeah. [slaps head] That's true. You and Carsten are correct.
-- Alex
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
participants (4)
-
Alex Balashov -
Carsten Bock -
Daniel-Constantin Mierla -
Efelin Novak