|
List Info
Thread: "*" and "#" signs in the userinfo of SIP URI
|
|
| "*" and "#" signs
in the userinfo of SIP URI |

|
2007-03-01 06:15:25 |
|
|
The latest draft draft-rosen-iptel-dialstring-06.txt defines a way of transporting the "*" and "#" signs using the "E and "F" signs respectively.
"A new alternative value for the "userinfo" parameter of the 'sip:' or 'sips:' URI schemes is defined, "dialstring". This value may be used in a 'sip:' or 'sips:' URI when the user part is a dial string. The dialstring is a sequence of the characters 0-9, A-F, P, X, '*' and "#'. E represents *, F represents #, P is a pause (short wait, like a comma in a modem string) and X represents "wait for call completion"
What is the rationale behind this alternative?
There is already a defined way of transporting this signs and bringing new alternative does support interoperability.
RFC 3261 says:
"The BNF for telephone-subscriber can be found in RFC 2806 [9].
Note, however, that any characters allowed there that are not allowed in
the user part of the SIP URI MUST be escaped."
The 3966 (obsolets 2806) defines the transport of the hex digits and "*" "#" signs:
local-number-digits = *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
Greetings,
Denis Alexeitsev
|
| RE: "*" and "#"
signs in the userinfo of SIP URI |
  Sweden |
2007-03-01 07:42:01 |
|
| Hi
Dennis,
In a
SIP-URI you can't transport "*" or "#" unescapted - even with user=phone. It was
discussed a while ago, and I proposed that it should be allowed to send them
unescaped in a SIP-URI (I know that some implementations do
it).
Whether that is the rationale I don't know, but reading the draft text
you copied I would assume it is...
Regards,
Christer
The latest draft
draft-rosen-iptel-dialstring-06.txt defines a way of transporting the "*" and
"#" signs using the "E and "F" signs respectively.
"A new alternative value for the "userinfo"
parameter of the 'sip:' or 'sips:' URI schemes is defined, "dialstring". This
value may be used in a 'sip:' or 'sips:' URI when the user part is a dial
string. The dialstring is a sequence of the characters 0-9, A-F, P, X, '*' and
"#'. E represents *, F represents #, P is a pause (short wait, like a comma in
a modem string) and X represents "wait for call completion"
What is the rationale behind this
alternative?
There is already a defined way of transporting this
signs and bringing new alternative does support interoperability.
RFC 3261 says:
"The BNF for telephone-subscriber can be found in
RFC 2806 [9]. Note, however, that any
characters allowed there that are not allowed in the user part of the SIP URI MUST be escaped."
The 3966 (obsolets 2806) defines the transport of
the hex digits and "*" "#" signs:
local-number-digits = *phonedigit-hex (HEXDIG
/ "*" / "#")*phonedigit-hex
Greetings, Denis
Alexeitsev |
| Re: "*" and "#"
signs in the userinfo of SIP URI |
  United States |
2007-03-01 09:10:32 |
I never liked the use of E and F for * and #. Its my
impression
(somebody correct me if I am wrong) that of the 16 possible
DTMF tones,
14 are mapped to 0..D, and the other two are mapped to * and
#. So there
is at least a temptation to see this as a hex encoding and
call * and #
E and F.
I'm happy to see * and # supported. I don't mind so much if
E and F are
also supported, though it could present issues during URI
comparison.
But dial strings have other issues in comparison, so this
probably is
not a big deal.
Paul
Alexeitsev, D wrote:
> The latest draft draft-rosen-iptel-dialstring-06.txt
defines a way of
> transporting the "*" and "#" signs
using the "E and "F" signs respectively.
>
> "A new alternative value for the
"userinfo" parameter of the 'sip:' or
> 'sips:' URI schemes is defined, "dialstring".
This value may be used in
> a 'sip:' or 'sips:' URI when the user part is a dial
string. The
> dialstring is a sequence of the characters 0-9, A-F, P,
X, '*' and "#'.
> E represents *, F represents #, P is a pause (short
wait, like a comma
> in a modem string) and X represents "wait for call
completion"
>
> What is the rationale behind this alternative?
>
> There is already a defined way of transporting this
signs and bringing
> new alternative does support interoperability.
>
> RFC 3261 says:
>
> "The BNF for telephone-subscriber can be found in
RFC 2806 [9].
> Note, however, that any characters allowed there that
are not allowed in
> the user part of the SIP URI MUST be escaped."
>
> The 3966 (obsolets 2806) defines the transport of the
hex digits and "*"
> "#" signs:
>
> local-number-digits = *phonedigit-hex (HEXDIG /
"*" / "#")*phonedigit-hex
>
> Greetings,
> Denis Alexeitsev
>
>
>
------------------------------------------------------------
------------
>
> _______________________________________________
> Iptel mailing list
> Iptel ietf.org
> https://
www1.ietf.org/mailman/listinfo/iptel
_______________________________________________
Iptel mailing list
Iptel ietf.org
https://
www1.ietf.org/mailman/listinfo/iptel
|
|
| RE: "*" and "#"
signs in the userinfo of SIP URI |

|
2007-03-02 00:47:23 |
Christer Holmberg (JO/LMF) writes:
> In a SIP-URI you can't transport "*" or
"#" unescapted - even with
> user=phone.
last time i checked, * was valid char in userpart of sip
uri.
> It was discussed a while ago, and I proposed that it
should
> be allowed to send them unescaped in a SIP-URI (I know
that some
> implementations do it).
yes, some implementation send # unescaped, but it makes NO
SENSE to
define yet another way to send #, since it can be sent
escaped.
-- juha
_______________________________________________
Iptel mailing list
Iptel ietf.org
https://
www1.ietf.org/mailman/listinfo/iptel
|
|
[1-4]
|
|