git:alexh/master: core modules/tm modules/sl: Make adding path and flags to redirected contacts optional
8 Aug
2011
8 Aug
'11
11:11 a.m.
Module: sip-router
Branch: alexh/master
Commit: 5c0d3f66e240686c4eda3f73928a64de266bb37e
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5c0d3f6…
Author: Alex Hermann <alex(a)speakup.nl>
Committer: Alex Hermann <alex(a)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=5c0…
8 Aug
8 Aug
11:18 a.m.
New subject: git:alexh/master: core modules/tm modules/sl: Make adding path and flags to redirected contacts optional
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.
--
Greetings,
Alex Hermann
11:21 a.m.
Am 08.08.2011 11:18, schrieb Alex Hermann:
On Monday 08 August 2011, Alex Hermann wrote:
What is a "redirecting registrar with Path support"?
Klaus
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.
11:38 a.m.
New subject: git:alexh/master: core modules/tm modules/sl: Make adding path and flags to redirected contacts optional
On Monday 08 August 2011, Klaus Darilion wrote:
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";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.
--
Greetings,
Alex Hermann
On Monday 08 August 2011, Alex Hermann wrote:
What is a "redirecting registrar with Path support"? 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.
2:29 p.m.
Am 08.08.2011 11:38, schrieb 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?
regards
Klaus
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";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.
On Monday 08 August 2011, Alex Hermann wrote:
What is a "redirecting registrar with Path support"? 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.
3:05 p.m.
New subject: git:alexh/master: core modules/tm modules/sl: Make adding path and flags to redirected contacts optional
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"? 
11:58 a.m.
New subject: git:alexh/master: core modules/tm modules/sl: Make adding path and flags to redirected contacts optional
8 aug 2011 kl. 11:18 skrev Alex Hermann:
On Monday 08 August 2011, Alex Hermann wrote:
How do you define "redirecting registrar"? A registrar that redirects REGISTER
requests to another server? Or a redirect server with registrar/location?
/O
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.
12:34 p.m.
New subject: git:alexh/master: core modules/tm modules/sl: Make adding path and flags to redirected contacts optional
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.
--
Greetings,
Alex Hermann
4863
days inactive
4863
days old
7 comments
3 participants
participants (3)
-
Alex Hermann -
Klaus Darilion -
Olle E Johansson