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.