> > 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

Reply via email to