Module: sip-router Branch: alexh/master Commit: 5c0d3f66e240686c4eda3f73928a64de266bb37e URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5c0d3f66...
Author: Alex Hermann alex@speakup.nl Committer: Alex Hermann alex@speakup.nl Date: Tue Jul 26 12:36:56 2011 +0200
core modules/tm modules/sl: Make adding path and flags to redirected contacts optional
---
dset.c | 24 ++++++----- dset.h | 6 ++- modules/sl/README | 22 +++++++++- modules/sl/doc/params.xml | 30 +++++++++++++++ modules/sl/sl.c | 1 + modules/sl/sl_funcs.c | 5 ++- modules/sl/sl_funcs.h | 2 + modules/tm/README | 92 ++++++++++++++++++++++++++------------------ modules/tm/doc/params.xml | 30 +++++++++++++++ modules/tm/t_reply.c | 5 ++- modules/tm/tm.c | 1 + modules_k/pv/pv_core.c | 2 +- modules_s/xlog/xl_lib.c | 2 +- 13 files changed, 165 insertions(+), 57 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=5c0d...
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.
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"?
Klaus
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";nat
hostb: bflags: 2 Path: sip:192.168.1.2:5060;lr;received;"sip:192.168.1.18:1144;transport;udp";nat
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%3blr%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%3d%22sip:192.168.1.18:1144%3btransport%3dudp%22%3bnat;q=0;flags=2.
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";nat
hostb: bflags: 2 Path: sip:192.168.1.2:5060;lr;received;"sip:192.168.1.18:1144;transport;udp";nat
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%3blr%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%3d%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?
regards Klaus
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@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.
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.
8 aug 2011 kl. 11:18 skrev 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.
How do you define "redirecting registrar"? A registrar that redirects REGISTER requests to another server? Or a redirect server with registrar/location?
/O
On Monday 08 August 2011, Olle E Johansson wrote:
How do you define "redirecting registrar"? A registrar that redirects REGISTER requests to another server? Or a redirect server with registrar/location?
INVITE's sent by the proxy to the registrar for registered AOR's are not routed directly by the registrar, but the registrar returns the Contacts in a 302 to the proxy.
My reply to Klaus has more details, if you need more info, let me know.