2012/4/16 Juha Heinanen <jh(a)tutpro.com>om>: 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. -- Iñaki Baz Castillo <ibc(a)aliax.net>

Daniel-Constantin Mierla writes: 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

2012/4/16 Daniel-Constantin Mierla <miconda(a)gmail.com>om>: 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. -- Iñaki Baz Castillo <ibc(a)aliax.net>

2012/4/16 Daniel-Constantin Mierla <miconda(a)gmail.com>om>: 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). Right, or also an ICMP error (if implemented). Outbound RFC 5626 is NOT just for stream connections, it is also for UDP. -- Iñaki Baz Castillo <ibc(a)aliax.net>

2012/4/16 Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt;om>: 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 :) 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. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;