[sr-dev] indicating gruu support

[Iñaki Baz Castillo]

2012/4/16 Daniel-Constantin Mierla <miconda at 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 at 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.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>