daniel,
i noticed that master sr assumes gruu support if ua includes +sip.instance contact param in register request, because contact in 200 ok response contains gruu params.
according to rfc5627 gruu support is indicated by
Supported: gruu
that is, +sip.instance contact param is not enough.
could you fix this by making supported gruu test before adding gruu contact params in 200 ok to register request?
-- juha
16 apr 2012 kl. 15:53 skrev Juha Heinanen:
daniel,
i noticed that master sr assumes gruu support if ua includes +sip.instance contact param in register request, because contact in 200 ok response contains gruu params.
according to rfc5627 gruu support is indicated by
Supported: gruu
that is, +sip.instance contact param is not enough.
could you fix this by making supported gruu test before adding gruu contact params in 200 ok to register request?
Note that +sip.instance is also used in SIP outbound.
/O
Olle E. Johansson writes:
Note that +sip.instance is also used in SIP outbound.
yes, i know, but in order to use it for gruu, supported gruu MUST be included:
When a UA compliant to this specification generates a REGISTER request (initial or refresh), it MUST include the Supported header field in the request. The value of that header field MUST include "gruu" as one of the option tags. This alerts the registrar for the domain that the UA supports the GRUU mechanism.
-- juha
2012/4/16 Juha Heinanen jh@tutpro.com:
Note that +sip.instance is also used in SIP outbound.
yes, i know, but in order to use it for gruu, supported gruu MUST be included:
When a UA compliant to this specification generates a REGISTER request (initial or refresh), it MUST include the Supported header field in the request. The value of that header field MUST include "gruu" as one of the option tags. This alerts the registrar for the domain that the UA supports the GRUU mechanism.
I agree. GRUU usage must be only performed if the client announces support for it. As Olle pointed, the existence of +sip.instance Contact header parameter does not mean "GRUU", it could just indicate Outbound support.
Regards.
Hello,
the parser for supported header was extended to detect gruu tag, but I haven't added the check for it because I had not time yet to look properly over 5626 to see what parts are common in regard to sip.instance.
I think that pub-gruu and temp-gruu should not be added to Contact header in the reply if gruu is missing in Supported header. Otherwise the sip.instance wii be used to match registration updates. If anyone can provide a short summary of 5626, regarding the registrar behavior, will be appreciated and can save some time.
On the other hand, if the device doesn't understand gruu, it will just ignore the temp/pub gruu addresses (they are header parameters) -- snom does it since it implement an old draft of gruu (-02 according to their wiki) , where only 'gruu' parameter was specified.
Cheers, Daniel
On 4/16/12 4:43 PM, Iñaki Baz Castillo wrote:
2012/4/16 Juha Heinanenjh@tutpro.com:
Note that +sip.instance is also used in SIP outbound.
yes, i know, but in order to use it for gruu, supported gruu MUST be included:
When a UA compliant to this specification generates a REGISTER request (initial or refresh), it MUST include the Supported header field in the request. The value of that header field MUST include "gruu" as one of the option tags. This alerts the registrar for the domain that the UA supports the GRUU mechanism.
I agree. GRUU usage must be only performed if the client announces support for it. As Olle pointed, the existence of +sip.instance Contact header parameter does not mean "GRUU", it could just indicate Outbound support.
Regards.
Daniel-Constantin Mierla writes:
On the other hand, if the device doesn't understand gruu, it will just ignore the temp/pub gruu addresses (they are header parameters) -- snom does it since it implement an old draft of gruu (-02 according to their wiki) , where only 'gruu' parameter was specified.
i agree that if ua does not support gruu, it can ignore the extra params, but it is waste of proxy resources and increases packet size if gruu params are included for vain.
-- juha
Hello,
On 4/16/12 6:13 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
On the other hand, if the device doesn't understand gruu, it will just ignore the temp/pub gruu addresses (they are header parameters) -- snom does it since it implement an old draft of gruu (-02 according to their wiki) , where only 'gruu' parameter was specified.
i agree that if ua does not support gruu, it can ignore the extra params, but it is waste of proxy resources and increases packet size if gruu params are included for vain.
agree, the check on supported header will be added once sorted out the overlapping with 5626. My note had only the role of clarifying that is harmless in terms of SIP routing.
Cheers, Daniel
2012/4/16 Daniel-Constantin Mierla miconda@gmail.com:
the parser for supported header was extended to detect gruu tag, but I haven't added the check for it because I had not time yet to look properly over 5626 to see what parts are common in regard to sip.instance. I think that pub-gruu and temp-gruu should not be added to Contact header in the reply if gruu is missing in Supported header. Otherwise the sip.instance wii be used to match registration updates. If anyone can provide a short summary of 5626, regarding the registrar behavior, will be appreciated and can save some time.
RFC 5626, in the registrar side, states that when the REGISTER contains a *single* Contact header with a *single* Contact URI, and the Contact header contains +sip.instance parameter (and the request includes "Supported: outbound") then the registrar should not check the Contact URI for operation in the location db, but instead take the +sip.instance value for matching purposes: the Contact URI MUST NOT be matched following SIP URI classic comparison.
Also take into account that RFC 5626 also mentions the ;reg-id Contact *header* param. A SIP client could send two REGISTER indicating same ;+sip.instance value and different ;reg-id values (1 and 2). When the registrar receives a request for the registered AoR it retrieves a single binding for all those existing bindings sharing ;+sip.instance, probably the binding with reg-id=1. If the connection is closed, then the registrar removes that binding and performs failover by using the binding with ;reg-id=2.
If there is an outbound proxy between the SIP client and the registrar, and the outbound proxy implements Outbound, and if the request from the registrar receives a "430 Flow Failed" from the Outbound proxy, the registrar should also remove such a binding (;reg-id=1) and try another one if present.
Regards.
On 4/16/12 7:28 PM, Iñaki Baz Castillo wrote:
2012/4/16 Daniel-Constantin Mierlamiconda@gmail.com:
the parser for supported header was extended to detect gruu tag, but I haven't added the check for it because I had not time yet to look properly over 5626 to see what parts are common in regard to sip.instance. I think that pub-gruu and temp-gruu should not be added to Contact header in the reply if gruu is missing in Supported header. Otherwise the sip.instance wii be used to match registration updates. If anyone can provide a short summary of 5626, regarding the registrar behavior, will be appreciated and can save some time.
RFC 5626, in the registrar side, states that when the REGISTER contains a *single* Contact header with a *single* Contact URI, and the Contact header contains +sip.instance parameter (and the request includes "Supported: outbound") then the registrar should not check the Contact URI for operation in the location db, but instead take the +sip.instance value for matching purposes: the Contact URI MUST NOT be matched following SIP URI classic comparison.
right, this is done -- if +sip.instance is present, the matching is done based on that token for existing contacts of the AoR in REGISTER's To header.
Also take into account that RFC 5626 also mentions the ;reg-id Contact *header* param. A SIP client could send two REGISTER indicating same ;+sip.instance value and different ;reg-id values (1 and 2). When the registrar receives a request for the registered AoR it retrieves a single binding for all those existing bindings sharing ;+sip.instance, probably the binding with reg-id=1. If the connection is closed, then the registrar removes that binding and performs failover by using the binding with ;reg-id=2.
So, even for same +sip.instance value can be several contact records, but with different reg-id?
If there is an outbound proxy between the SIP client and the registrar, and the outbound proxy implements Outbound, and if the request from the registrar receives a "430 Flow Failed" from the Outbound proxy, the registrar should also remove such a binding (;reg-id=1) and try another one if present.
Is reg-id special for stream connections (tcp/tls)? Or if there is a timeout on UDP, same behavior should apply, ie, remove the contact address?
Thanks, Daniel
Regards.
2012/4/16 Daniel-Constantin Mierla miconda@gmail.com:
Also take into account that RFC 5626 also mentions the ;reg-id Contact *header* param. A SIP client could send two REGISTER indicating same ;+sip.instance value and different ;reg-id values (1 and 2). When the registrar receives a request for the registered AoR it retrieves a single binding for all those existing bindings sharing ;+sip.instance, probably the binding with reg-id=1. If the connection is closed, then the registrar removes that binding and performs failover by using the binding with ;reg-id=2.
So, even for same +sip.instance value can be several contact records, but with different reg-id?
Right. That's for registration failover:
Outbund-Proxy-1 UA Registrar Outbund-Proxy-2
or:
Registrar-1 UA Registrar-2
(both Registrar-1 and Registrar-2 sharing same DB).
The UA mantains two registrations alive, same +sip.instance (since it's the SAME device) but different reg-id values.
NOTE that for this to work, the UA must be provided with two registration URI's or two Outbound proxies (or more).
If there is an outbound proxy between the SIP client and the registrar, and the outbound proxy implements Outbound, and if the request from the registrar receives a "430 Flow Failed" from the Outbound proxy, the registrar should also remove such a binding (;reg-id=1) and try another one if present.
Is reg-id special for stream connections (tcp/tls)? Or if there is a timeout on UDP, same behavior should apply, ie, remove the contact address?
Right, or also an ICMP error (if implemented). Outbound RFC 5626 is NOT just for stream connections, it is also for UDP.
On 4/16/12 7:47 PM, Iñaki Baz Castillo wrote:
2012/4/16 Daniel-Constantin Mierlamiconda@gmail.com:
Also take into account that RFC 5626 also mentions the ;reg-id Contact *header* param. A SIP client could send two REGISTER indicating same ;+sip.instance value and different ;reg-id values (1 and 2). When the registrar receives a request for the registered AoR it retrieves a single binding for all those existing bindings sharing ;+sip.instance, probably the binding with reg-id=1. If the connection is closed, then the registrar removes that binding and performs failover by using the binding with ;reg-id=2.
So, even for same +sip.instance value can be several contact records, but with different reg-id?
Right. That's for registration failover:
Outbund-Proxy-1UA Registrar Outbund-Proxy-2
or:
Registrar-1UA Registrar-2
(both Registrar-1 and Registrar-2 sharing same DB).
The UA mantains two registrations alive, same +sip.instance (since it's the SAME device) but different reg-id values.
NOTE that for this to work, the UA must be provided with two registration URI's or two Outbound proxies (or more).
so the failover should be done also for request within dialog, but this would be possible only in combination with gruu.
Is there a rule saying if a reg-id value sets priority of contact address, such as reg-id=1 must be selected first, and then reg-id=2, ...
Cheers, Daniel
2012/4/16 Daniel-Constantin Mierla miconda@gmail.com:
so the failover should be done also for request within dialog, but this would be possible only in combination with gruu.
AFAIK there is no failover defined for in-dialog requests. Take into account that, when Outbound is used, the Contact URI of an INVITE/200 is useless (it could point to a private address) since the routing information is in the username part of a Record-Route added by the proxy during the initial INVITE:
Record-Route: sip:qweahgdfh@IP_PROXY;transport=xx;lr
Such a "qweahgdfh" token is a "connection identifier" which lets the proxy (by examining the Route header in in-dialog requests) getting the connection to be used for routing the request. In case of UDP the token contain the IP:port of the peer (hashed in some way).
But in case there is no Outbound proxy (but just a single registrar+proxy) then there could be in-dialog failover (in case of GRUU):
- The Contact URI of the INVITE/200 contains a GRUU URI. - The GRUU URI points to a +sip.instace. - But a +sip.instance can point to more than a single reg-id, so in case the first one (probably reg-id=1) is closed, then the registrar could use the second one.
That would be really cool indeed :)
Is there a rule saying if a reg-id value sets priority of contact address, such as reg-id=1 must be selected first, and then reg-id=2, ...
No, it seems that the registrar could choose anyone, but (AFAIK) once it has selected a reg-id, then it should use it forever (until it's unregistered by the UA, expired, closed or failed).
RFC 5626
3.1. Summary of Mechanism
Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Each UA can register multiple times over different flows for the same SIP Address of Record (AOR) to achieve high reliability. Each registration includes the instance-id for the UA and a reg-id label that is different for each flow. The registrar can use the instance-id to recognize that two different registrations both correspond to the same UA. The registrar can use the reg-id label to recognize whether a UA is creating a new flow or refreshing or replacing an old one, possibly after a reboot or a network failure.
When a proxy goes to route a message to a UA for which it has a binding, it can use any one of the flows on which a successful registration has been completed. A failure to deliver a request on a particular flow can be tried again on an alternate flow.
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Juha Heinanen -
Olle E. Johansson