Alex,
On 11/4/16 12:31 AM, Alex Balashov wrote:
Hi,
As far as I can tell from the RFC 3261 ABNF, it is permitted to put SEMI
and EQUAL in the username of a URI, but it has no semantic validity.
Why do you say this has no semantic validity? The owner of the domain
determines the semantics of the user part of the URI. Some domains may
choose to use these for something.
That is to say, this is permitted:
<sip:myval=abc;user@domain:5060>
but doesn't mean anything. 'myval=abc;user' is just one big long username:
It *means* whatever 'domain' wants it to mean.
SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]
SIPS-URI = "sips:" [ userinfo ] hostport
uri-parameters [ headers ]
userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
And yet, there are some specs out there which put tokens which are
semantically key=value parameters in the user part of a URI, and expect
equipment to extract their values. One spec in particular that comes to
mind is RFC 4694 ("Number Portability Parameters for the "tel" URI"),
which explicitly contemplates outcomes like this:
Contact: <sip:14045551212;npdi;rn=14045550000@domain>
... with the expectation that portability-aware equipment will harvest
the value of the 'rn' parameter, much as it would a uri-parameter or a
header parameter. In fact, as I understand it, the whole idea behind
this approach is that the essential bareword - '14045551212' - remains
the user part of the RURI, the canonical dialed destination. The other
parameters can be ignored by equipment that doesn't understand them.
I see Brett already responded and pointed to the stuff about tel URIs
being mapped to SIP URIs.
So, how does that work? Is the voodoo that gives username-embedded
parameters meaning embedded somehow in the complex rules governing the
conversion of 'tel:' scheme URIs to 'sip:'? Or am I mistaken in my
assumption that parameters cannot be embedded in the user part of a URI
to begin with?
These are not sip-uri-parameters. They are something else. They have
meaning when processing telephone numbers.
To be honest, this is a bit of a mess in SIP. In particular, the user=
parameter is a mess. One way to interpret it is that the user part of
the URI should be interpreted differently for user=phone and user=ip.
But this can't be entirely true, because a registrar is supposed to
disgregard URI parameters when registering a contact in the location
service.
So, practically speaking, a domain that handles phone numbers at all had
better arrange things so user parts that look like tel URIs are
processed like phone numbers.
Also, common practice has evolved so that when the user part looks like
a phone number intermediaries often feel free to ignore the domain name
and process just the phone number. Sometimes they only do this when
user=phone is present, sometimes not. IMO this is *wrong* - that when
the domain is present then routing must be to the domain, and
interpretation of the user part should only be done within the domain.
(If you don't want that, then use a tel URI.) But I seem to have lost
that battle.
The ultimate reason for asking is that I am looking to embed a parameter
like this in a Diversion URI.
Well, Diversion was never standardized. Its use in the wild is entirely
proprietary. So feel free to do whatever seems to work for you.
I am dealing with a gateway that will try
a redirect destination, and if it fails to reach that destination, will
call me again, and send me a Diversion header anew. The Diversion header
is rebuilt and doesn't pass on any URI or header parameters I include,
but if I stick something in the username, I'll get it back. I need it
for a piece of application state. However, before I go this route, I
need to have some idea of whether there's any justification for the
expectation that my extra parameter will be ignored by equipment which
doesn't understand it. Otherwise, I'm just screwing up the diverted
phone number.
I don't fully understand. But if you are effectively just "talking to
yourself" then feel free to do anything that is syntactically valid.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
