28 Apr
2013
28 Apr
'13
8:16 p.m.
i have one more comment on flow token vs. contact aliasing.
flow token is part of a route uri that represent a proxy in the route
set. route set cannot be changed during the dialog, but remote target
uri can. from rfc3261:
Requests within a dialog MAY contain Record-Route and Contact header
fields. However, these requests do not cause the dialog's route set
to be modified, although they may modify the remote target URI.
Specifically, requests that are not target refresh requests do not
modify the dialog's remote target URI, and requests that are target
refresh requests do. For dialogs that have been established with an
INVITE, the only target refresh request defined is re-INVITE (see
Section 14). Other extensions may define different target refresh
requests for dialogs established in other ways.
Note that an ACK is NOT a target refresh request.
Target refresh requests only update the dialog's remote target URI,
and not the route set formed from the Record-Route.
if flow token is used instead of contact aliasing to store the remote
target uri, then it is not possible to modify the remote target uri via
target refresh requests (e.g. when moving from wifi to mobile network)
and such setup is violating the above text of rfc3261.
this problem does not exist with contact aliasing, because
add_contact_alias() is called on each in-dialog target refresh request,
which allows changing of remote target uri during the dialog.
-- juha
28 Apr
28 Apr
10:37 p.m.
Hi Juha,
This sounds like a bug with the outbound specification. I can't believe
that the ability to re-target dialogs would be deliberately removed by the
outbound enhancement without it being mentioned in the RFC.
Perhaps the right thing to do would be to raise this issue on the
appropriate IETF mailing lists and seeing if the designers of the
specification have an opinion rather than just using a proprietary
solution like contact aliasing?
Regards,
Peter
i have one more comment on flow token vs. contact
aliasing.
flow token is part of a route uri that represent a proxy in the route
set. route set cannot be changed during the dialog, but remote target
uri can. from rfc3261:
Requests within a dialog MAY contain Record-Route and Contact header
fields. However, these requests do not cause the dialog's route set
to be modified, although they may modify the remote target URI.
Specifically, requests that are not target refresh requests do not
modify the dialog's remote target URI, and requests that are target
refresh requests do. For dialogs that have been established with an
INVITE, the only target refresh request defined is re-INVITE (see
Section 14). Other extensions may define different target refresh
requests for dialogs established in other ways.
Note that an ACK is NOT a target refresh request.
Target refresh requests only update the dialog's remote target URI,
and not the route set formed from the Record-Route.
if flow token is used instead of contact aliasing to store the remote
target uri, then it is not possible to modify the remote target uri via
target refresh requests (e.g. when moving from wifi to mobile network)
and such setup is violating the above text of rfc3261.
this problem does not exist with contact aliasing, because
add_contact_alias() is called on each in-dialog target refresh request,
which allows changing of remote target uri during the dialog.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
10:46 p.m.
Peter Dunkley writes:
This sounds like a bug with the outbound
specification. I can't believe
that the ability to re-target dialogs would be deliberately removed by the
outbound enhancement without it being mentioned in the RFC.
my opinion about outbound rfc is that its only useful bits are
requirement to register via at least two proxies and that ua has to take
care of keepalives. the flow token stuff is useless and, as i
mentioned, breaks rfc3261. gruu (or if not supported, contact aliasing)
is the solution for getting in-dialog requests to registered UAs.
Perhaps the right thing to do would be to raise this
issue on the
appropriate IETF mailing lists and seeing if the designers of the
specification have an opinion rather than just using a proprietary
solution like contact aliasing?
i'm out of that loop myself. perhaps someone else on this list is on
some of the ietf or sip implementors mailing lists.
-- juha
29 Apr
29 Apr
11:10 a.m.
28 apr 2013 kl. 21:46 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Peter Dunkley writes:
Considering how many years it took to complete SIP outbound I'm
surprised over this issue.
The flow-token needs to change.
/O
This sounds like a bug with the outbound
specification. I can't believe
that the ability to re-target dialogs would be deliberately removed by the
outbound enhancement without it being mentioned in the RFC.
my opinion about outbound rfc is that its only useful bits are
requirement to register via at least two proxies and that ua has to take
care of keepalives. the flow token stuff is useless and, as i
mentioned, breaks rfc3261. gruu (or if not supported, contact aliasing)
is the solution for getting in-dialog requests to registered UAs.
Perhaps the right thing to do would be to raise
this issue on the
appropriate IETF mailing lists and seeing if the designers of the
specification have an opinion rather than just using a proprietary
solution like contact aliasing?
i'm out of that loop myself. perhaps someone else on this list is on
some of the ietf or sip implementors mailing lists.
10:09 a.m.
This was discussed briefly at a SIPit a few years ago. Outbound seems to
focus on session setup, not session management. What happens
if a connection goes down and a device re-registers with a new
reg-id during a call?
I think you two have hit a very good issue with outbound that needs
to be discussed.
/O
28 apr 2013 kl. 21:37 skrev "Peter Dunkley"
<peter.dunkley(a)crocodile-rcs.com>om>:
Hi Juha,
This sounds like a bug with the outbound specification. I can't believe
that the ability to re-target dialogs would be deliberately removed by the
outbound enhancement without it being mentioned in the RFC.
Perhaps the right thing to do would be to raise this issue on the
appropriate IETF mailing lists and seeing if the designers of the
specification have an opinion rather than just using a proprietary
solution like contact aliasing?
Regards,
Peter
i have one more comment on flow token vs. contact
aliasing.
flow token is part of a route uri that represent a proxy in the route
set. route set cannot be changed during the dialog, but remote target
uri can. from rfc3261:
Requests within a dialog MAY contain Record-Route and Contact header
fields. However, these requests do not cause the dialog's route set
to be modified, although they may modify the remote target URI.
Specifically, requests that are not target refresh requests do not
modify the dialog's remote target URI, and requests that are target
refresh requests do. For dialogs that have been established with an
INVITE, the only target refresh request defined is re-INVITE (see
Section 14). Other extensions may define different target refresh
requests for dialogs established in other ways.
Note that an ACK is NOT a target refresh request.
Target refresh requests only update the dialog's remote target URI,
and not the route set formed from the Record-Route.
if flow token is used instead of contact aliasing to store the remote
target uri, then it is not possible to modify the remote target uri via
target refresh requests (e.g. when moving from wifi to mobile network)
and such setup is violating the above text of rfc3261.
this problem does not exist with contact aliasing, because
add_contact_alias() is called on each in-dialog target refresh request,
which allows changing of remote target uri during the dialog.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
10:27 a.m.
Olle E. Johansson writes:
This was discussed briefly at a SIPit a few years ago.
Outbound seems to
focus on session setup, not session management. What happens
if a connection goes down and a device re-registers with a new
reg-id during a call?
reg-id does not need to be new. if ua looses tcp connection to ob proxy
and sets up a new one, reg-id will not change. if flow tokens are in
use in route set, that ua cannot be reached anymore for in-dialog
requests, which is a bad thing and breaks rfc 3261. therefore, a
standards compliant sip proxy cannot be configured to use flow tokens in
its route uris.
-- juha
10:55 a.m.
29 apr 2013 kl. 09:27 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Olle E. Johansson writes:
If you have multiple edge proxys, say four, and a device use two of them,
reg-id will change as it registers with number three when number one dies...
But yes, this is something that needs to be looked into.
/O
This was discussed briefly at a SIPit a few years
ago. Outbound seems to
focus on session setup, not session management. What happens
if a connection goes down and a device re-registers with a new
reg-id during a call?
reg-id does not need to be new. if ua looses tcp connection to ob proxy
and sets up a new one, reg-id will not change. if flow tokens are in
use in route set, that ua cannot be reached anymore for in-dialog
requests, which is a bad thing and breaks rfc 3261. therefore, a
standards compliant sip proxy cannot be configured to use flow tokens in
its route uris.
12:55 p.m.
29 apr 2013 kl. 09:27 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Olle E. Johansson writes:
After a chat with Peter I decided to send a mail to the IETF dispatch wg:
http://www.ietf.org/mail-archive/web/dispatch/current/msg04855.html
/O
This was discussed briefly at a SIPit a few years
ago. Outbound seems to
focus on session setup, not session management. What happens
if a connection goes down and a device re-registers with a new
reg-id during a call?
reg-id does not need to be new. if ua looses tcp connection to ob proxy
and sets up a new one, reg-id will not change. if flow tokens are in
use in route set, that ua cannot be reached anymore for in-dialog
requests, which is a bad thing and breaks rfc 3261. therefore, a
standards compliant sip proxy cannot be configured to use flow tokens in
its route uris.
4228
days inactive
4229
days old
7 comments
3 participants
participants (3)
-
Juha Heinanen -
Olle E. Johansson -
Peter Dunkley