On 12/28/12 8:45 AM, Theo Zourzouvillys wrote:
> On Tue, Dec 18, 2012 at 4:24 PM, Paul Kyzivat <[email protected]> wrote:
>> I don't think so. But maybe others will find a justification for doing so.
>
> I don't think it is valid - although it's totally underspecified.
>
> user=phone implies the user portion is a tel URI, and
> tel:anonymous.invalid;phone-context=+1 isn't legitimate - so i can see
> why a parser would fail it, as even if it was matching a
> local-phone-number only hex digits would be allowed.
Yeah, that makes some sense.
3261 is indeed underspecified about this. What it says is:
The user URI parameter exists to
distinguish telephone numbers from user names that happen to
look like telephone numbers. If the user string contains a
telephone number formatted as a telephone-subscriber, the user
parameter value "phone" SHOULD be present.
It doesn't ever say the flip of that: "If the user parameter value
"phone" is present, the user string (SHOULD/MUST?) be formatted as a
telephone-subscriber".
If that is not so, then the parameter doesn't have a lot of value.
> perhaps an interoperable stack would treat any user=phone URI which
> fails to parse as a normal SIP URI. That said, as it's only used in
> the contact header, the user portion has no semantic meaning (as Paul
> pointed out it has the maddr parameter), i'd be tempted to treat it as
> an opaque string after extracting enough routing information and just
> include it in the response. Not sure other intermediaries will
> correctly handle any requests with it as the R-URI though.
This could be a problem for a stack that parses the entire message,
stores it in parsed form, and then regenerates it from the parsed form
to pass on. (Things that don't parse can't be stored in parsed form.)
(That's a warning for stack implementers.)
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
