Module: sip-router Branch: master Commit: 948e083f7c681b9aaa8729aea019ebea3ee1ac2c URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=948e083f...
Author: Miklos Tirpak miklos@iptel.org Committer: Miklos Tirpak miklos@iptel.org Date: Wed May 13 14:57:26 2009 +0200
@ruri.params["foo"] checks also the original sip: URI parameters
This patch increases the compatibility with non-standard implementations when the parameters are added to the end of the sip: URI instead of the userinfo part in case of a tel: URI embedded in a sip: URI. For example: sip:123@domain;foo=bar;user=phone instead of sip:123;foo=bar@domain;user=phone
---
select_core.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/select_core.c b/select_core.c index 68a1b37..ffe874d 100644 --- a/select_core.c +++ b/select_core.c @@ -806,6 +806,7 @@ int select_uri_proto(str* res, select_t* s, struct sip_msg* msg)
int select_uri_params(str* res, select_t* s, struct sip_msg* msg) { + int ret; if (!msg || !res) { return select_any_params(res, s, msg); } @@ -817,7 +818,16 @@ int select_uri_params(str* res, select_t* s, struct sip_msg* msg) RETURN0_res(uri.params);
*res=uri.params; - return select_any_params(res, s, msg); + ret = select_any_params(res, s, msg); + if ((ret < 0) + && (uri.sip_params.s != NULL) + && (uri.sip_params.s != uri.params.s) + ) { + /* Search also in the original sip: uri parameters. */ + *res = uri.sip_params; + ret = select_any_params(res, s, msg); + } + return ret; }
int select_any_params(str* res, select_t* s, struct sip_msg* msg)
On Wed, May 13, 2009 at 3:06 PM, Miklos Tirpak miklos@iptel.org wrote: (snip)
This patch increases the compatibility with non-standard implementations when the parameters are added to the end of the sip: URI instead of the userinfo part in case of a tel: URI embedded in a sip: URI. For example: sip:123@domain;foo=bar;user=phone instead of sip:123;foo=bar@domain;user=phone
Despite that RFC 3261, Section 19.1.6 states that when a TEL URI (RFC 2806) is converted to a SIP URI, the entire telephone-subscriber portion of the TEL URI, _including any parameters_, should be placed into the userinfo part of the SIP URI, deployment experiences showed that this may raise some interoperability issues: basically, there are good chances that one network element will strip or will be unable to parse userinfo parameters.
For the sake of completeness, a typical use case would be number portability-related information in the SIP URI (RFC4694 only addresses the TEL URI), where some elements support/carry them as URI-userinfo parameters (as defined per RFC 3261) while others do so as URI parameters.
Cheers,