Hi, for now, the "normal" way to detect if an in-dialog request/response beyonds to a natted dialog is by adding a uri parameter ("nat=yes") in the "Contact" header of the first request and response and macthing that parameter in the RURI of subsequent in-dialog requests.
Typically this is done in this way:
search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
Well, this mechanims (that is part of official OpenSer courses) is very RCF3261 non compliant:
1) In SIP a header field name is case insensitive but the above function wouldn't match a "CONTACT" of "contact" header names (even if they are 100% valid).
2) "Contact" header can appear abbreviated as "m" (or "M") but the above doesn't match it.
3) 1.1.1. Known Limitations search ignores folded lines. For example, search("(From|f):.*@foo.bar") doesn't match the following From header field: From: medabeda sip:medameda@foo.bar;tag=1234
A solution for points 1 and 2 could be using "subst" with insensitive flag enabled, but it could be very anti-friendly.
So I wonder: wouldn't be useful a good funtion to add/read/remove header and uri parameters (in any header or uri) being RFC 3261 compliant (this is: case insensitive and allowing header name abbreviations)?
El Domingo, 10 de Agosto de 2008, Iñaki Baz Castillo escribió:
search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
4) An **always** present bug in any openser.cfg: The URI protocol is also case insensitive, so it could be "sip", "SIP", "Sip"... (also the above code doesn't match "sips" protocol).
In any openser.cfg the RURI is matched using: if $ru == "^sip:0034[0-9]+@"
This contains the same problem as above explained.
PD: I'd like to know how much interest exists to make OpenSer/Kamailio as more RFC compliant as possible. Well, I'm the first thinking that RFC 3261 is a pain because it's too much permissive (lowcase is enough in 99% of cases and easier to code, why 99% of the SIP BNF allows case insensitive?, why painful line-folding? why so many MAY instead of MUST?). Anyway RFC3261 (and much more RFC's) is what we have. Is OpenSer target to be super RFC compliant even if it looses performance?
Thanks.
El Domingo, 10 de Agosto de 2008, Iñaki Baz Castillo escribió:
- An **always** present bug in any openser.cfg: The URI protocol is also
case insensitive, so it could be "sip", "SIP", "Sip"... (also the above code doesn't match "sips" protocol).
In any openser.cfg the RURI is matched using: if $ru == "^sip:0034[0-9]+@"
This contains the same problem as above explained.
I'm really sorry, OpenSer does it OK, it matches "sip", "SIP" in case insensitive. ;)
Iñaki Baz Castillo writes:
Hi, for now, the "normal" way to detect if an in-dialog request/response beyonds to a natted dialog is by adding a uri parameter ("nat=yes") in the "Contact" header of the first request and response and macthing that parameter in the RURI of subsequent in-dialog requests.
instead of contact header, you could use rr header.
-- juha
2008/8/11, Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
Hi, for now, the "normal" way to detect if an in-dialog request/response beyonds to a natted dialog is by adding a uri parameter ("nat=yes") in the "Contact" header of the first request and response and macthing that parameter in the RURI of subsequent in-dialog requests.
instead of contact header, you could use rr header.
Yep, in fact finally I used "rr" :)
-
Iñaki Baz Castillo -
jh＠tutpro.com