El Miércoles, 13 de Enero de 2010, Brett Tate escribió: > > > 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.
True, for example a TEL URI allows "#" symbol while it's not allowed in a SIP URI userinfo part. > 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? Do you mean a tel uri like this?: tel:anonymous;phone-context=national No, the parser doesn't allow it as it's invalid according to tel-subscriber grammar. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
