I'm going to get a bit nit-picky here. The text from 3261 says:
The set of valid telephone-subscriber strings is a subset of
valid user strings. 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. Even without this
parameter, recipients of SIP and SIPS URIs MAY interpret the
pre-@ part as a telephone number if local restrictions on the
name space for user name allow it.
This says that if the user field contains an e164 telephone-subscriber
than user=phone SHOULD be present. It doesn't state the converse: that
if the user part *doesn't* contain a telephone-subscriber then there
should *not* be a user=phone.
So I don't think this can be viewed as a syntactic error. It needs to be
considered a semantic distinction and only considered by something
responsible for the domain that has knowledge of the semantics of user
names in that domain.
Thanks,
Paul
Brett Tate wrote:
>>> In case it matters, "anonymous" does violate the character
>>> set for the digits portion of telephone-subscriber. Thus
>>> although maybe not desirable, a strict parser may reject
>>> the INVITE with a 400 response.
>> It's just a semantic subject. No strict SIP parser should
>> reject such SIP URI even if its username part doesn't conform
>> to telephone-subscriber grammar when "user=phone" parameter
>> is present.
>
> The sender indicated user=phone when user portion cannot really be decoded
> (per BNF character restrictions) into a telephone-subscriber. Thus a vendor
> may choose to reject the request.
>
> Concerning the topic, I've heard of a vendor's protocol monitor (or similar
> device not directly involved within the call) being overly restrictive
> concerning ability to decode telephone-subscriber when user=phone. If I
> recall correctly, the user portion of sip-uri was "anonymous" or there was no
> user portion. The abnormal situation was causing them problems; I have no
> idea if they have relaxed their decoder.
>
>
>> I've tested it with my SIP parser which is 100% strict
>> according to RFC 3261 grammar and RFC 3966 (TEL). Such
>> SIP URI is valid according to BNF.
>
> Does your parser allow invalid characters within the local-number-digits or
> does it not allow "anonymous;phone-context=national" to successfully decode
> into a telephone-subscriber?
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
