i noticed that if i add ;alias param to contact header that does not surround its contact uri in <>s like this:
Contact: sip:foo@bar;alias=value
then some sip entities interpret ;alias as header param rather than uri param.
so i went and added <>s if they are not present resulting to this:
Contact: sip:foo@bar;alias=value
i have tried to figure out from rfc3261 what kind of param ;alias is in the first example, but have not found the answer. looks like it is unspecified in rfc3261.
any comments on this?
-- juha
2010/11/26 Juha Heinanen jh@tutpro.com:
i noticed that if i add ;alias param to contact header that does not surround its contact uri in <>s like this:
Contact: sip:foo@bar;alias=value
In this header, "alias" is a header parameter. 100% sure.
then some sip entities interpret ;alias as header param rather than uri param.
so i went and added <>s if they are not present resulting to this:
Contact: sip:foo@bar;alias=value
In this case "alias" is a SIP URI parameter.
i have tried to figure out from rfc3261 what kind of param ;alias is in the first example, but have not found the answer. looks like it is unspecified in rfc3261.
It's specified in the BNF grammar and AFAIR somewhere else. But I can sure that what I say above is correct.
Iñaki Baz Castillo writes:
Contact: sip:foo@bar;alias=value
In this header, "alias" is a header parameter. 100% sure.
inaki,
based on what in rfc3261 syntax?
Contact = ("Contact" / "m" ) HCOLON ( STAR / (contact-param *(COMMA contact-param))) contact-param = (name-addr / addr-spec) *(SEMI contact-params) name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = SIP-URI / SIPS-URI / absoluteURI display-name = *(token LWS)/ quoted-string contact-params = c-p-q / c-p-expires / contact-extension
SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] my reading of the above is that the whole contact body can be an addr-spec.
-- juha
2010/11/26 Juha Heinanen jh@tutpro.com:
inaki,
based on what in rfc3261 syntax?
Contact = ("Contact" / "m" ) HCOLON ( STAR / (contact-param *(COMMA contact-param))) contact-param = (name-addr / addr-spec) *(SEMI contact-params) name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = SIP-URI / SIPS-URI / absoluteURI display-name = *(token LWS)/ quoted-string contact-params = c-p-q / c-p-expires / contact-extension
SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ]
my reading of the above is that the whole contact body can be an addr-spec.
Juha, I can ensure you that I'm right, I studied it a lot some time ago. In fact, Contact has similar syntax than From header (but Contact allows various entries separated by comma). It's very common to see the following From format:
From: sip:alice@domain.org;tag=qweqwe
For sure, Fromtag MUST be a header param and not a URI param (as Fromtag is defined to be a header param in RFC3261).
RURI is a addr-spec, so any param in the RURI is, of course, a URI param. But in case a From/Contact/To header contains a addr-spec then a param is ALWAYS a header param. If you want to add a URI param in these headers you MUST user name-addr format.
One more argument:
contact-param = (name-addr / addr-spec) *(SEMI contact-params)
Imagine you use addr-spec, you want a URI param ";uri-param=1234" and a header param ";header-param=9999". How would it look?:
Contact: sip:alice@dom.org;uri-param=1234;header-param=9999
If you were right, how to determine that ;uri-param is a URI param and ;header-param is a header param? There is no way! So the only solution is using name-addr:
Contact: sip:alice@dom.org;uri-param=1234;header-param=9999
This is a complex grammar in the RFC 3261, and there have been long discussions about it in sip-implementors maillist, you can search for them if you want.
my reading of the above is that the whole contact body can be an addr-spec.
Yes, of course, but then it CANNOT contain URI params, just header params.
Regards.
On 11/26/10 1:56 PM, Iñaki Baz Castillo wrote:
[...]
Juha, I can ensure you that I'm right, I studied it a lot some time ago. In fact, Contact has similar syntax than From header (but Contact allows various entries separated by comma). It's very common to see the following From format:
From: sip:alice@domain.org;tag=qweqwe
For sure, Fromtag MUST be a header param and not a URI param (as Fromtag is defined to be a header param in RFC3261).
I am also positive about this, if there are no arrow brackets, then it is a header parameter. But I cannot say now exactly where is specified.
Cheers, Daniel
2010/11/26 Daniel-Constantin Mierla miconda@gmail.com:
For sure, Fromtag MUST be a header param and not a URI param (as Fromtag is defined to be a header param in RFC3261).
I am also positive about this, if there are no arrow brackets, then it is a header parameter. But I cannot say now exactly where is specified.
Section 20:
The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.
On 11/26/10 2:14 PM, Iñaki Baz Castillo wrote:
2010/11/26 Daniel-Constantin Mierlamiconda@gmail.com:
For sure, Fromtag MUST be a header param and not a URI param (as Fromtag is defined to be a header param in RFC3261).
I am also positive about this, if there are no arrow brackets, then it is a header parameter. But I cannot say now exactly where is specified.
Section 20:
The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and>). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.
Right, thanks for pointing it.
Cheers, Daniel
Iñaki Baz Castillo writes:
Section 20:
The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.
thanks, that was what i was looking for.
-- juha
2010/11/26 Juha Heinanen jh@tutpro.com:
Section 20:
The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.
thanks, that was what i was looking for.
:)
Iñaki Baz Castillo writes:
RURI is a addr-spec, so any param in the RURI is, of course, a URI param. But in case a From/Contact/To header contains a addr-spec then a param is ALWAYS a header param.
where is that stated in rfc3261? it is not enough to me that you assure so. my counter argument could be that if there are no <>s, then every param is uri param and that viewpoint is fully supported by the syntax.
One more argument:
contact-param = (name-addr / addr-spec) *(SEMI contact-params)
Imagine you use addr-spec, you want a URI param ";uri-param=1234" and a header param ";header-param=9999". How would it look?:
Contact: sip:alice@dom.org;uri-param=1234;header-param=9999
i can claim that you cannot use addr-spec if you want to use header params, i.e., you must use <>s and haeder params will follow.
If you were right, how to determine that ;uri-param is a URI param and ;header-param is a header param? There is no way!
see above. if you want header param, you must use <> syntax.
So the only solution is using name-addr:
Contact: sip:alice@dom.org;uri-param=1234;header-param=9999
exactly, but if there are no <>s, then what? i can justify the claim that then all params are uri params.
This is a complex grammar in the RFC 3261, and there have been long discussions about it in sip-implementors maillist, you can search for them if you want.
i don't want, but it is really strange that there is such a bug in the grammar that has not been fixed by some other rfc.
Yes, of course, but then it CANNOT contain URI params, just header params.
that is just your opinion that so far you have not based on any fact in rfc3261.
-- juha
2010/11/26 Juha Heinanen jh@tutpro.com:
This is a complex grammar in the RFC 3261, and there have been long discussions about it in sip-implementors maillist, you can search for them if you want.
i don't want, but it is really strange that there is such a bug in the grammar that has not been fixed by some other rfc.
It's not a bug in the grammar. The BNF grammar is not the only source of specification. For example, RFC 3261 BNF states that Contact header can contain a "*" chat as value, but the "Registration" section defines that it can only be used for deŕegistering all the contacts.
Yes, of course, but then it CANNOT contain URI params, just header params.
that is just your opinion that so far you have not based on any fact in rfc3261.
Isn't it enough?:
Section 20:
The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.
Juha, I ensured it to you because I spent long time with it some time ago, but in a first try I couldn't find the RFC 3261 section in which this is defined. Now you already have it.
Regards.
2010/11/26 Iñaki Baz Castillo ibc@aliax.net:
Juha, I ensured it to you because I spent long time with it some time ago
There you have a thread in sip-implementors about this issue:
http://www.mail-archive.com/sip-implementors@lists.cs.columbia.edu/msg02194....
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Juha Heinanen