Based on the discussions about outbound and in-dialog routing it seems like we need to use GRUU and live with the fact that the route-set changes (in breach of RFC 3261).
Can anyone share a Kamailio registrar configuration that uses GRUU to look-up in-dialog requests (preferably one that makes use of t_load_contacts(), t_next_contact(), and t_next_contact_flow())?
Regards,
Peter
Peter Dunkley writes:
Based on the discussions about outbound and in-dialog routing it seems like we need to use GRUU and live with the fact that the route-set changes (in breach of RFC 3261).
why would route set (the one recorded by record-route headers) change because of gruu? it doesn't in my tests.
Can anyone share a Kamailio registrar configuration that uses GRUU to look-up in-dialog requests (preferably one that makes use of t_load_contacts(), t_next_contact(), and t_next_contact_flow())?
in-dialog requests don't deal with those t_ functions. after loose_route() i use this:
if ($du == "") { if (is_gruu()) { if (!lookup("location")) { send_reply("404", "Not Found"); exit; } else { xlog("L_INFO", "Routing in-dialog $rm <$ru> from <$fu> to <$du>\n"); };
-- juha
If you look at the recent (yesterday and today) discussion on DISPATCH the conclusion appears to be that this is how it should work and that RFC 5626 should have been clearer on the behaviour.
Regards,
Peter
On 30/04/13 19:03, Juha Heinanen wrote:
Peter Dunkley writes:
Based on the discussions about outbound and in-dialog routing it seems like we need to use GRUU and live with the fact that the route-set changes (in breach of RFC 3261).
why would route set (the one recorded by record-route headers) change because of gruu? it doesn't in my tests.
Can anyone share a Kamailio registrar configuration that uses GRUU to look-up in-dialog requests (preferably one that makes use of t_load_contacts(), t_next_contact(), and t_next_contact_flow())?
in-dialog requests don't deal with those t_ functions. after loose_route() i use this:
if ($du == "") { if (is_gruu()) { if (!lookup("location")) { send_reply("404", "Not Found"); exit; } else { xlog("L_INFO", "Routing in-dialog $rm <$ru> from <$fu> to <$du>\n"); };-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Peter Dunkley writes:
If you look at the recent (yesterday and today) discussion on DISPATCH the conclusion appears to be that this is how it should work and that RFC 5626 should have been clearer on the behaviour.
i read the discussion and don't understand why would route set change. if ua looses connection to its proxy, it sets up a new one, but the proxy (which is in the route set established by r-r headers) is still the same.
-- juha
By enabling the route-set to change you can failover to another flow within dialog. This gives you protection against sessions terminating because the connection between the client and one of the edge proxies dies.
If you cannot change the route-set and one of your connections to the edge proxy fails you will never be able to route another request on that dialog.
Regards,
Peter
On 30/04/13 19:16, Juha Heinanen wrote:
Peter Dunkley writes:
If you look at the recent (yesterday and today) discussion on DISPATCH the conclusion appears to be that this is how it should work and that RFC 5626 should have been clearer on the behaviour.
i read the discussion and don't understand why would route set change. if ua looses connection to its proxy, it sets up a new one, but the proxy (which is in the route set established by r-r headers) is still the same.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Peter Dunkley writes:
By enabling the route-set to change you can failover to another flow within dialog. This gives you protection against sessions terminating because the connection between the client and one of the edge proxies dies.
If you cannot change the route-set and one of your connections to the edge proxy fails you will never be able to route another request on that dialog.
yes you can if the edge proxy is still alive and client establishes a new connection to it (as it according to outbound rfc should do).
-- juha
The client can take several minutes to notice (it seems to take between 3 minutes and 7 minutes depending on the OS) that a TCP connection has died.
This leaves a substantial window that requests to the client are undeliverable.
Re-routing in-dialog requests when the flow fails solves this problem.
Regards,
Peter
Peter Dunkley writes:
By enabling the route-set to change you can failover to another flow within dialog. This gives you protection against sessions terminating because the connection between the client and one of the edge proxies dies.
If you cannot change the route-set and one of your connections to the edge proxy fails you will never be able to route another request on that dialog.
yes you can if the edge proxy is still alive and client establishes a new connection to it (as it according to outbound rfc should do).
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Peter Dunkley writes:
The client can take several minutes to notice (it seems to take between 3 minutes and 7 minutes depending on the OS) that a TCP connection has died.
This leaves a substantial window that requests to the client are undeliverable.
Re-routing in-dialog requests when the flow fails solves this problem.
yes, if in the example that i gave in previous message p1 (through which the call was setup) is still alive, but only connection to between ua1 and p1 has died, then bye from ua2 would reach ua1 from p1 to p2 to ua1 if p1 does lookup on the gruu of ua1 and after that does the t_load_contact/t_next_contacts/t_next_contact_flow thing. in that case, there would be no change in the route set as long as no flow tokens are included in the r-r uris.
-- juha
Juha Heinanen writes:
yes, if in the example that i gave in previous message p1 (through which the call was setup) is still alive, but only connection to between ua1 and p1 has died, then bye from ua2 would reach ua1 from p1 to p2 to ua1 if p1 does lookup on the gruu of ua1 and after that does the t_load_contact/t_next_contacts/t_next_contact_flow thing. in that case, there would be no change in the route set as long as no flow tokens are included in the r-r uris.
forgot to mention that i have not been able to test this outbound/gruu scenario, because i don't know any sip client that would implement both outbound and gruu.
-- juha
JsSIP seems to do this now. Although it only creates a single flow.
Flow-tokens get added to Path: headers for REGISTERs, but they do not get added to the Record-Route: headers for INVITEs (because the INVITE contains a GRUU Contact: without an ;ob parameter). This is correct under RFC5626.
To get in-dialog routing to work correctly for this stack (when GRUU and outbound are enabled on Kamailio) you need to always do a location lookup() when the R-URI is a GRUU URI.
In route[WITHINDLG] I now do something like:
if (has_totag()) { if (is_gruu()) { route[LOCATION]; } else if (loose_route()) {
} else {
} exit; }
Juha Heinanen writes:
yes, if in the example that i gave in previous message p1 (through which the call was setup) is still alive, but only connection to between ua1 and p1 has died, then bye from ua2 would reach ua1 from p1 to p2 to ua1 if p1 does lookup on the gruu of ua1 and after that does the t_load_contact/t_next_contacts/t_next_contact_flow thing. in that case, there would be no change in the route set as long as no flow tokens are included in the r-r uris.
forgot to mention that i have not been able to test this outbound/gruu scenario, because i don't know any sip client that would implement both outbound and gruu.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Peter Dunkley writes:
JsSIP seems to do this now. Although it only creates a single flow.
yes i know and that is violation of outbound rfc where at least two is MUST. so as long as jssip only creates one flow, it is not implementing outbound and i cannot use it in my outbound tests.
Flow-tokens get added to Path: headers for REGISTERs, but they do not get added to the Record-Route: headers for INVITEs (because the INVITE contains a GRUU Contact: without an ;ob parameter). This is correct under RFC5626.
that is fine then.
To get in-dialog routing to work correctly for this stack (when GRUU and outbound are enablned on Kamailio) you need to always do a location lookup() when the R-URI is a GRUU URI.
In route[WITHINDLG] I now do something like:
if (has_totag()) { if (is_gruu()) { route[LOCATION]; } else if (loose_route()) {
} else { } exit; }
this is pretty close to what i have except i call loose_route first to see if i'm the last hop and it makes sense to do location lookup
i still fail to see when would route set change during the call and especially magically without a re-invite.
-- juha
by the way, i don't know how jssip does it, but if i restart my proxy, it recognizes it immediate and two seconds later it re-registers.
-- juha
On proxy restart the TCP connection is dropped and I assume this is triggering the re-registration.
On Tue, Apr 30, 2013 at 4:17 PM, Juha Heinanen jh@tutpro.com wrote:
by the way, i don't know how jssip does it, but if i restart my proxy, it recognizes it immediate and two seconds later it re-registers.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
I think the right place for a discussion on what is the right protocol behaviour is on DISPATCH.
The opinion there (from the only two people who participated in the discussion) seemed to be that you used GRUU and ignored the route-set and (as a result of the flow-tokens stored in the Path: headers) this made everything work - even though it broke RFC 3261 route-set behaviour.
Ultimately, the current Kamailio implementation can handle whatever way people want to do this in real-world deployments. One thing that is clear is that RFC5626 could do with some clarification in this area.
Regards,
Peter
On proxy restart the TCP connection is dropped and I assume this is triggering the re-registration.
On Tue, Apr 30, 2013 at 4:17 PM, Juha Heinanen jh@tutpro.com wrote:
by the way, i don't know how jssip does it, but if i restart my proxy, it recognizes it immediate and two seconds later it re-registers.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- VoIP Embedded, Inc. http://www.voipembedded.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
30 apr 2013 kl. 20:16 skrev Juha Heinanen jh@tutpro.com:
Peter Dunkley writes:
If you look at the recent (yesterday and today) discussion on DISPATCH the conclusion appears to be that this is how it should work and that RFC 5626 should have been clearer on the behaviour.
i read the discussion and don't understand why would route set change. if ua looses connection to its proxy, it sets up a new one, but the proxy (which is in the route set established by r-r headers) is still the same.
If you are using edge proxys separate from the registrar, the new registration may come through another edge proxy, so the gruu will resolve in a new path to the client, which replaces the existing route through the possibly dead edge proxy.
/O
Hi all,
2013/5/2 Olle E. Johansson oej@edvina.net
30 apr 2013 kl. 20:16 skrev Juha Heinanen jh@tutpro.com:
Peter Dunkley writes:
If you look at the recent (yesterday and today) discussion on DISPATCH the conclusion appears to be that this is how it should work and that RFC 5626 should have been clearer on the behaviour.
i read the discussion and don't understand why would route set change. if ua looses connection to its proxy, it sets up a new one, but the proxy (which is in the route set established by r-r headers) is still the same.
If you are using edge proxys separate from the registrar, the new registration may come through another edge proxy, so the gruu will resolve in a new path to the client, which replaces the existing route through the possibly dead edge proxy.
Such new path to the client will be used instead of the old and invalid one as far as I understand from RFC 5626, chapter 7:
```
The proxy uses the next-hop target of the message and the value of any stored Path header field vector in the registration binding to decide how to forward and populate the Route header in the request. If the proxy is co-located with the registrar and stored information about the flow to the UA that created the binding, then the proxy MUST send the request over the same 'logical flow' saved with the binding, since that flow is known to deliver data to the specific target UA instance's network flow that was saved with the binding.
```
Which means that a newly created registration binding (following the procedures defined in chapter 4.4) will contain the PATH route with the new and valid flow token, and such 'logical flow' MUST be used instead of that in the Route. Hence, the Route header(s) pointing to the old and deprecated 'logical flow' is replaced with the new one gathered from the registration after the flow failure.
/O
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Olle E. Johansson writes:
If you are using edge proxys separate from the registrar, the new registration may come through another edge proxy, so the gruu will resolve in a new path to the client, which replaces the existing route through the possibly dead edge proxy.
yes, but the parties of the call are sending in-dialog requests based on the route set that was created when the dialog was established. if the edge proxy that was used to setup the call dies, there is no way that bye will ever get to the working edge proxy unless r-r uri that the now dead edge proxy inserted, contains a domain name in its hostpart. i don't remember seeing in outbound rfc such a requirement.
-- juha
for example, lets say that ua1 has two ob proxies p1 and p2. then ua1 sets up invite dialog to ua2 through p1, which adds itself to the route set. if p1 dies, ua1 could send a re-invite to ua2 via p2 that is record-routed by p2 and that would cause the route set change first at ua1 and, when 200 ok comes back, also at ua1.
this would work, but would be a major change from rfc3261, which does not require record routing of re-reinvites and learning of new route sets based on every in-dialog request and 200 ok reply. it would thus mean new behavior both in proxies and in sip uas.
one standards compliant way to solve this problem would be use of domain name in r-r header that is common to both p1 and p2:
The URI placed in the Record-Route header field MUST resolve to the element inserting it (or a suitable stand-in) when the server location procedures of [4] are applied to it, so that subsequent requests reach the same SIP element.
i don't know if kamailio and existing UAs would be able to cope with that.
-- juha
-
José Luis Millán -
Juha Heinanen -
Olle E. Johansson -
Ovidiu Sas -
Peter Dunkley