8 Aug
2011
8 Aug
'11
9:05 a.m.
On Monday 08 August 2011, Klaus Darilion wrote:
Am 08.08.2011 11:38, schrieb Alex Hermann:
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
On Monday 08 August 2011, Klaus Darilion wrote:
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? Am 08.08.2011 11:18, schrieb Alex Hermann:
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@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@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. 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"?