[sr-dev] git:alexh/master: core modules/tm modules/sl: Make adding path and flags to redirected contacts optional

[Alex Hermann]

On Monday 08 August 2011, Klaus Darilion wrote:
> Am 08.08.2011 11:38, schrieb Alex Hermann:
> > On Monday 08 August 2011, Klaus Darilion wrote:
> >> Am 08.08.2011 11:18, schrieb Alex Hermann:
> >>> On Monday 08 August 2011, Alex Hermann wrote:
> >>>> Commit: 5c0d3f66e240686c4eda3f73928a64de266bb37e
> >>>> Commit: 0ef0618e2273dfd717014d4caa484f7f20f0a2c1
> >>>> core/dset: Create contacts with path vector as Route header
> >>>> 
> >>>> Commit: 74af2df4b37cae1b72c964eed0d1d80cc499f64e
> >>>> core/dset: Create contacts with flags as header parameter
> >>>> 
> >>>> core modules/tm modules/sl: Make adding path and flags to redirected
> >>>> contacts optional
> >>>> 
> >>>> Commit: e430827e3501181992596dd950ea0e36b41c084b
> >>>> modules_k/uac_redirect: Parse Contact's "flags" header parameter into
> >>>> branch flags.
> >>>> 
> >>>> Commit: 54e95bd7a9411f89a52774de0e457c0baa4556ef
> >>>> modules_k/uac_redirect: Make using the flags Contact-header-parameter
> >>>> configurable
> >>> 
> >>> The above set of commits make it possible to make a redirecting
> >>> registrar with Path support and forwarding branch flags. Not sure if
> >>> this is usefull at all for others. If so, please let me know and i'll
> >>> commit it to master.
> >> 
> >> What is a "redirecting registrar with Path support"?
> > 
> > A registrar receives an invite from the proxy with the aor in the ruri.
> > The registrar replies with a 302 with all the registered contacts for
> > that aor. This is already possible ofcourse, but this set of patches
> > enhance the Contact with a Route header containing the Path vector (if
> > present) and a header parameter with the branch flags.
> > 
> > Now the proxy can honor the Path by routing using the added Route header
> > and for example NAT support can be done because the proxy now had the
> > branch flags of each contact.
> > 
> > Example:
> > 
> > hosta: bflags: 2 Path:
> > sip:192.168.1.2:5060;lr;received="sip:192.168.1.18:2048;transport;udp";na
> > t
> > 
> > hostb: bflags: 2 Path:
> > sip:192.168.1.2:5060;lr;received;"sip:192.168.1.18:1144;transport;udp";na
> > t
> > 
> > 
> > 
> > Results in the following contact header in the 302:
> > 
> > Contact:
> > <sip:hosta at 172.28.4.223:2048;line=b5psbzj0?Route=sip:192.168.1.2:5060%3bl
> > r%3breceived%3d%22sip:192.168.1.18:2048%3btransport%3dudp%22%3bnat>;q=0.3
> > ;flags=2,
> > <sip:hostb at 172.28.4.40:2048?Route=sip:192.168.1.2:5060%3blr%3breceived%3
> > d%22sip:192.168.1.18:1144%3btransport%3dudp%22%3bnat>;q=0;flags=2.
> 
> Are there any clients that do support the Route header in the Contact
> URI? Or do you use it just for your own proprietary setup?

It is standards conform, see rfc 3327 and documentation of sip-router's path 
module. Clients don't send the header in the Contact, it is added by the 
registrar to the Contact in the 302 if a Path vector is present.

In the proxy receiving the 302, the Contacts become the route-set and the 
route header for each branch is added to the SIP request (and $du is set to 
it). The request is then sent.

The flags parameter is not defined in a standard.

-- 
Greetings,

Alex Hermann