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.