30 Apr
2013
30 Apr
'13
7:56 p.m.
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
30 Apr
30 Apr
8:03 p.m.
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
8:11 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
8:16 p.m.
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
8:35 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
8:50 p.m.
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
9:22 p.m.
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:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:37 p.m.
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
9:40 p.m.
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
10:04 p.m.
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:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
10:13 p.m.
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
10:17 p.m.
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
10:23 p.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
VoIP Embedded, Inc.
http://www.voipembedded.com
11:50 p.m.
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(a)tutpro.com> wrote:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2 May
2 May
8:34 a.m.
30 apr 2013 kl. 20:16 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Peter Dunkley 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.
/O
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. 
10:40 a.m.
Hi all,
2013/5/2 Olle E. Johansson <oej(a)edvina.net>
30 apr 2013 kl. 20:16 skrev Juha Heinanen <jh(a)tutpro.com>om>:
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.
Peter Dunkley 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.
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.
/O
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
José Luis Millán
3 May
3 May
9:05 p.m.
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
30 Apr
30 Apr
9:22 p.m.
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
4010
days inactive
4013
days old
17 comments
5 participants
participants (5)
-
José Luis Millán -
Juha Heinanen -
Olle E. Johansson -
Ovidiu Sas -
Peter Dunkley