[sr-dev] indicating gruu support

Iñaki Baz Castillo ibc at aliax.net
Mon Apr 16 19:28:17 CEST 2012


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

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



More information about the sr-dev mailing list