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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
28 apr 2013 kl. 21:46 skrev Juha Heinanen jh@tutpro.com:
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.
Considering how many years it took to complete SIP outbound I'm surprised over this issue.
The flow-token needs to change. /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?
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@crocodile-rcs.com:
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
29 apr 2013 kl. 09:27 skrev Juha Heinanen jh@tutpro.com:
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.
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
29 apr 2013 kl. 09:27 skrev Juha Heinanen jh@tutpro.com:
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.
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
-
Juha Heinanen -
Olle E. Johansson -
Peter Dunkley