Subject: [Sip] Escaping rules of SIP-URI userpart

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 28 Sep 2006 15:03:37 +0200

Hi,

Chapter 19.1.1 of RFC3261 says that the sip scheme follows the
guidelines in RFC2396. As a result of that, the "#" character is used to
used to delimit a URI from a fragment identifier, and if one wants to
use the "#" as a part of a URI value itself it must be escaped.

RFC3966 (TEL-URI) does allow the usage of "#" (unescaped) in
local-numbers.

The SIP-URI userpart shall be parsed as a TEL-URI telephone-subscriber
if user=phone is indicated, but according to chapter 19.1.2 of RFC3261
the "#" character must still be escaped.

My question is: why?

If the userpart is parsed as telephone-subscriber, there is no such
thing as a fragment identifier in the userpart, so why can't "#" be
unescaped in that case?

"#" will be used pretty much with service codes, and I think that being
forced to escape it is unecessary. Also, if you do a conversion between
a SIP-URI and TEL-URI you always need to check for this character, which
takes time.

Regards,

Christer

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 28 Sep 2006 16:17:09 +0300

> thing as a fragment identifier in the userpart, so why can't "#" be

i don't know what fragment identifier is, but most sip phones on the
market do not escape # in request-uri userpart and i haven't noticed any
problems associated with it.  so i suggest to allow # unescaped also in
sip uri userparts.

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 28 Sep 2006 15:20:52 +0200

Hi, 

>>If the userpart is parsed as telephone-subscriber, there 
>>is no such thing as a fragment identifier in the userpart, 
>>so why can't "#" be  > unescaped in that case?
> 
>i don't know what fragment identifier is, but most sip phones 
>on the market do not escape # in request-uri userpart and i 
>haven't noticed any problems associated with it.  so i 
>suggest to allow # unescaped also in sip uri userparts.

I have also seen SIP nodes using # unescaped in the userpart, and I
haven't heard of any problems.

Regards,

Christer

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 28 Sep 2006 15:27:42 +0200

Hi Christer,

for time ago I was asked the question how to handle # in a user URI.

Paul Kyzivat wrote this:
"
Not quite. RFC 3261 section 19.1.2 says:

    The telephone-subscriber subset of the user component has special
    escaping considerations.  The set of characters not reserved in the
    RFC 2806 [9] description of telephone-subscriber contains a number of
    characters in various syntax elements that need to be escaped when
    used in SIP URIs.  Any characters occurring in a telephone-subscriber
    that do not appear in an expansion of the BNF for the user rule MUST
    be escaped.

So you will have to go with: <sip:[email-masked]>".

I hope this helps.

Regards,
Markus

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 28 Sep 2006 15:35:08 +0200

Hi Markus,

I know what section 19.1.2 says.

The issue is that I don't understand why that rule is needed. User=phone
means that the userpart shall be parsed as a telephone-subscriber, and
within a telephone-subscriber the "#" does not have any special meaning,
so there is no need to escape it. 

So, yes, you probably have to go with:

sip:[email-masked]

But, I see no reason why you should have to go with:

sip:[email-masked];user=phone

Instead you could use:

sip:[email-masked];user=phone

Regards,

Christer

> -----Original Message-----
> From: Markus Hofmann [mailto:[email-masked]] 
> Sent: 28. syyskuuta 2006 16:28
> To: Christer Holmberg (JO/LMF)
> Cc: Juha Heinanen; [email-masked]
> Subject: Re: [Sip] Escaping rules of SIP-URI userpart
> 
> Hi Christer,
> 
> is no such 
> >> market do not escape # in request-uri userpart and i 
> haven't noticed 
> >> any problems associated with it.  so i suggest to allow # 
> unescaped 
> >> also in sip uri userparts.
> > 
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> 
>

---

From: [email-masked]
Date: Thu, 28 Sep 2006 10:42:16 -0400

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>

   sip:[email-masked]

   Instead you could use:

How would you write a left-to-right parser that could cope with that?

Dale

---

From: [email-masked]
Date: Thu, 28 Sep 2006 10:50:22 -0400

sipX is strict on URI syntax, and it rejects requests that don't
escape "#".  We've had some problems with that.

Dale

---

From: [email-masked]
Date: Thu, 28 Sep 2006 10:51:45 -0400

You have to check for more than that, as SIP allows *any* character to
be written as an escape.  If tel: URIs don't admit escaping, you have
to un-escape when you convert...

Dale

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 28 Sep 2006 18:03:23 +0200

Hi Dale,

[CHH] Well, you can't really perform a detailed parse of the userpart before you have parsed the user parameter anyway.
 
And, whatever the value of the user parameter is, I have never seen "#" used as this kind of delmiter in a SIP-URI anyway...
 
Regards,
 
Christer

 

Dale

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 28 Sep 2006 18:08:10 +0200

Hi Dale,

>to un-escape when you convert...

I do think that tel-URI also convert escaping, so  I guess you would only have to do the check when you map from TEL to SIP. But, that is bad enough :)

Regards,

Christer

Dale

---

From: [email-masked]
Date: Thu, 28 Sep 2006 13:59:10 -0400

And, whatever the value of the user parameter is, I have never seen
   "#" used as this kind of delmiter in a SIP-URI anyway...

Whether it has any use in a SIP URI is not particularly important --
as a URI it has to follow the generic syntax of URIs, RFC 2396.  And
RFC 2396 reserves the use of '#' for fragment identifiers.

Dale

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 28 Sep 2006 21:08:35 +0300

> RFC 2396 reserves the use of '#' for fragment identifiers.

there are various exceptions in rfc3261 regarding other standards that
rfc3261 uses.  why can't there be an exception on # too?

-- juha

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 28 Sep 2006 15:09:30 -0400

I suspect it might be because a SIP-URI could be placed elsewhere, like on 
some web page or in some other application that parses all URIs according to 
RFC 2396. Such a generic URI parser would interpret everything after the '#' 
as a fragment. This would result in a mis-interpretation of the URI.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 28 Sep 2006 21:17:14 +0200

Also, I don't think that the RFC 3261 ABNF even allows for the usage of
"#" as a delimiter, as defned in RFC2396.

Chapter 4 of RFC2396 says:

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

First, we can see that the fragment part cannot be within the URI, it
optionally follows the URI

Second, we can see that the fragment is not part of the URI, it is part
of URI
--Apple-Mail-9-775243422--

--=======22955542=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--=======22955542=--

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 28 Sep 2006 21:17:14 +0200

of URI-reference.

Third, there is no mentioning of URI-reference in the SIP ABNF.

For example, the Request-URI is defined as: 

Request-URI =  SIP-URI / SIPS-URI / absoluteURI

But, nowhere is ["#" fragment] mentioned. 

So, I doubt that many parsers implemented based on the SIP ABNF would
even accept a URI followed by a fragment in a SIP message.

Regards,

Christer

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 28. syyskuuta 2006 19:03
> To: [email-masked]; [email-masked]
> Subject: VS: [Sip] Escaping rules of SIP-URI userpart
> 
> Hi Dale,
> 
> 
> [CHH] Well, you can't really perform a detailed parse of the 
> userpart before you have parsed the user parameter anyway.
>  
> And, whatever the value of the user parameter is, I have 
> never seen "#" used as this kind of delmiter in a SIP-URI anyway...
>  
> Regards,
>  
> Christer
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> Dale
> 
> [email-masked] for questions on current sip 
> [email-masked] for questions on current sip 

-reference.

Third, there is no mentioning of URI-reference in the SIP ABNF.

For example, the Request-URI is defined as: 

Request-URI =  SIP-URI / SIPS-URI / absoluteURI

But, nowhere is ["#" fragment] mentioned. 

So, I doubt that many parsers implemented based on the SIP ABNF would
even accept a URI followed by a fragment in a SIP message.

Regards,

Christer

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 28. syyskuuta 2006 19:03
> To: [email-masked]; [email-masked]
> Subject: VS: [Sip] Escaping rules of SIP-URI userpart
> 
> Hi Dale,
> 
> 
> [CHH] Well, you can't really perform a detailed parse of the 
> userpart before you have parsed the user parameter anyway.
>  
> And, whatever the value of the user parameter is, I have 
> never seen "#" used as this kind of delmiter in a SIP-URI anyway...
>  
> Regards,
>  
> Christer
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> Dale
> 
> [email-masked] for questions on current sip 
> [email-masked] for questions on current sip

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 28 Sep 2006 21:28:00 +0200

Hi,

Again, when I read the SIP ABNF the only URIs that can be used are
absoluteURI, and of course SIP-URI, and none of these contain the
optional fragment part.

So, instead of:

...the ABNF should have said something like:

Request-URI   = ((SIP-URI / SIPS-URI)["#" fragment]) / URI-reference)

...or something like that.

Regards,

Christer 

> From: Bob Penfield [mailto:[email-masked]] 
> Sent: 28. syyskuuta 2006 22:10
> To: Juha Heinanen; [email-masked]
> Cc: [email-masked]
> I suspect it might be because a SIP-URI could be placed 
> elsewhere, like on some web page or in some other application 
> that parses all URIs according to RFC 2396. Such a generic 
> URI parser would interpret everything after the '#'

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 28 Sep 2006 15:47:15 -0400

True, but if the SIP-URI is held in a place where a URI-reference is 
allowed, everything after the # would be interpreted as a fragment. That is 
why 2396 indicates it needs to be escaped.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

----- Original Message ----- 
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "Juha Heinanen" 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 28, 2006 3:28 PM
Subject: RE: VS: [Sip] Escaping rules of SIP-URI userpart

Hi,

So, instead of:

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 28 Sep 2006 21:54:44 +0200

Hi Bob,

>True, but if the SIP-URI is held in a place where a URI-reference is
allowed, everything after the # would be 
>interpreted as a fragment. That is why 2396 indicates it needs to be
escaped.

Well, if you put your SIP-URI in such a place then escape what needs to
be escaped - but you don't need to escape it when inserted into a SIP
request.

And, in any case one of course needs to make sure that the fragment is
removed before the SIP-URI is inserted into a SIP request, since the SIP
ABNF doesn't allow it...

Regards,

Christer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Sep 2006 17:50:23 -0400

I agree here with Bob, Dale and others. The SIP URI is derived from RFC 
2396 and inherits its constraints. That is part of the cost of being a 
URI as opposed to a SIP-specific type of identifier. Just because some 
implementations have not followed the spec on this point does not change 
what the spec says or why its there.

-Jonathan R.

Bob Penfield wrote:

> allowed, everything after the # would be interpreted as a fragment. That 
> is why 2396 indicates it needs to be escaped.
> 
> cheers,
> (-:bob
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 71 Third Avenue
> Burlington, MA 01803
> [email-masked]
> 
> ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" 
> <[email-masked]>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 29 Sep 2006 05:31:57 +0200

Hi Jonathan,

No matter what people have implemented, the SIP ABNF does not allow the
fragment. The SIP-URI does not allow the fragment.

Regards,

Christer

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 29. syyskuuta 2006 0:50
> To: Bob Penfield
> Cc: Christer Holmberg (JO/LMF); Juha Heinanen; 
> [email-masked]; [email-masked]
> 2396 and inherits its constraints. That is part of the cost 
> of being a URI as opposed to a SIP-specific type of 
> identifier. Just because some implementations have not 
> followed the spec on this point does not change what the spec 
> says or why its there.
> 
> -Jonathan R.
> 
> Bob Penfield wrote:
> 
> > allowed, everything after the # would be interpreted as a fragment. 
> > That is why 2396 indicates it needs to be escaped.
> > 
> > cheers,
> > (-:bob
> > 
> > Robert F. Penfield
> > Chief Software Architect
> > Acme Packet, Inc.
> > 71 Third Avenue
> > Burlington, MA 01803
> > [email-masked]
> > 
> >> I suspect it might be because a SIP-URI could be placed elsewhere, 
> >> like on some web page or in some other application that parses all 
> >> URIs according to RFC 2396. Such a generic URI parser 
> would interpret 
> >> everything after the '#'

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 29 Sep 2006 12:44:09 +0200

Christer, Dale,
I really confused about this discussion regarding'#'.
The range of a telephone number Digit is 0,1,2...9,A,B,C,D,F as far as I know (it's a binary 4 Digit code ).
You can look in Q.764 which of the digits are used for what and also E.164 gives a guideline.

So for what Telephone application '#' is used?

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Christer Holmberg (JO/LMF) 
> Gesendet: Donnerstag, 28. September 2006 21:17
> An: [email-masked]; [email-masked]
> Betreff: RE: [Sip] Escaping rules of SIP-URI userpart
> 
> 
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 29 Sep 2006 12:55:29 +0200

Hi Roland, 

>The range of a telephone number Digit is 0,1,2...9,A,B,C,D,F 
>as far as I know (it's a binary 4 Digit code ).

You can use if for service codes. *21#3455

...or "Please enter your pin code, followed by #".

Regards,

Christer

> > Also, I don't think that the RFC 3261 ABNF even allows for 
> the usage 
> > of "#" as a delimiter, as defned in RFC2396.
> > 
> > Second, we can see that the fragment is not part of the URI, it is 
> > part of URI-reference.
> > 
> never seen

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 29 Sep 2006 12:59:25 +0200

>...or "Please enter your pin code, followed by #".

Well, that's a bad example, because you wouldn't send the pin code in a SIP-URI.

But, the service code example is still valid.

Regards,

Christer

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Fri, 29 Sep 2006 07:10:34 -0500

Binary Coded Decimal (BCD) 

-----Original Message-----
From: Jesske, R [mailto:[email-masked]] 
Sent: Friday, September 29, 2006 6:44 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: AW: [Sip] Escaping rules of SIP-URI userpart

Christer, Dale,

Best Regards

Roland

> the usage of

---

From: [email-masked]
Date: Fri, 29 Sep 2006 08:15:38 -0400

From: "Jesske, R" <[email-masked]>

   I really confused about this discussion regarding'#'.
   The range of a telephone number Digit is 0,1,2...9,A,B,C,D,F as far
   as I know (it's a binary 4 Digit code ).
   You can look in Q.764 which of the digits are used for what and
   also E.164 gives a guideline.

The real table of DTMF digits, laid out according to the organization
of the *dual tones*, is:

	1 2 3 A

	4 5 6 B

	7 8 9 C

	* 0 # D

but most keypads don't have the right-hand column.

You can also see "*" and "#" in the RTP encoding chart, RFC 2833
section 3.10.

"*" and "#" are used for invoking special features in many phone
systems.  (E.g., in sipX, "*78" is the default call pick-up code, and
"*4" the default call retrieval code.)

Also, when dialing calls for which the central office doesn't have
knowledge of when the dial string has ended (e.g., international
calls), "#" is used as a signal that the dial string is finished.

Dale

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 29 Sep 2006 18:35:21 +0300

> So for what Telephone application '#' is used?

operators use # in various prefixes to the dialled number, for example:

- #31#number means privacy off for this call

- #21# means turn off unconditional transfer

i suggest that sip proxy and phone vendors follow the usual ietf
practise: be liberal in what you accept.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 29 Sep 2006 13:47:00 -0500

> Sent: Friday, September 29, 2006 3:55 AM
> To: Jesske, R; [email-masked]; [email-masked]
> Subject: RE: [Sip] Escaping rules of SIP-URI userpart
> 
> 
> Hi Roland, 
> 

There is no need for this in a URI. The service code should be 
translatable by the phone to a real URI that actually means something.
 
> ...or "Please enter your pin code, followed by #".

That's not a phone number: it's dialled digits, and it is coverered by 
KPML and RFC 2833. It has no place in a URI.

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 29 Sep 2006 22:19:41 +0300

> translatable by the phone to a real URI that actually means

i don't understand what you are trying to say.  #31# prefix of phone
number, for example, means something to PSTN and needs to be carried
there from the SIP phone, which cannot have a clue of various PSTN dial
string conventions.  or can you explain what kind of magic translation
nortel SIP phones do when user dial #31# followed by a phone number?

-- juha

---

From: Byron Campen <[email-masked]>
Date: Fri, 29 Sep 2006 15:17:14 -0500

Sigh, I was hoping not to get wound up about this, but here I go...  
(comment inline)

> practise: be liberal in what you accept.

	And be conservative in what you send. (Postel's Law) This discussion  
is primarily about what a SIP UA should be willing to throw onto the  
wire. UAs have no business sending unescaped '#' onto the wire,  
because they are bound by the constraints of the aforementioned RFCs.  
If the receiving endpoint is unable to recognize the escaped form,  
and interpret it as '#', that is the fault of the receiving endpoint.  
(Not to mention a direct violation of the "be liberal in what you  
accept" clause of Postel's Law) It is infuriating that otherwise  
compliant UAs are being forced to engage in this broken behavior to  
pick up the slack.

Best regards,
Byron Campen

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Sep 2006 18:36:50 -0400

I'm speculating here, but perhaps AbsoluteURIs are forbidden from having 
unescaped # so that a URI-reference, with its use of #, can be 
unambiguously parsed.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 29 Sep 2006 18:25:38 -0500

Francois Audet writes:
> 
>  > There is no need for this in a URI. The service code 
> should be  > translatable by the phone to a real URI that 
> actually means  > something.
> 
> i don't understand what you are trying to say.  #31# prefix 
> of phone number, for example, means something to PSTN and 
> needs to be carried there from the SIP phone, which cannot 
> have a clue of various PSTN dial string conventions.  or can 
> you explain what kind of magic translation nortel SIP phones 
> do when user dial #31# followed by a phone number?

I'm saying doing what you are proposing, i.e., using # in a phone
number ON THE WIRE (I.e., in a URI), is an extremely bad idea that 
we shouldn't attempt to do in SIP. And it won't work except in
isolated proprietary implementations.

In the example you gave (I'm hearing that some network operator
is using this for privacy).

What you need to do is intercept the digit pattern in the phone,
make the call to the destination without the proprietary digits, and
then mark your From header as [email-masked].

To do it your way would MANDATE a B2BUA since my proxy would have
to remove the From and replace it (making it a B2BUA). And it would
magically have to understand all the dialling plans in the universe.

So publishing a URI with a # means most people won't
be able to reach it. #31# means absolutely nothing to me
in North America. If I try to call you with this, it just won't
work.  

As a side note, on many phones, "#" means end-of-dialling. 
It stops digit collection. And it is NOT transmitted on the wire.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 30 Sep 2006 01:56:02 +0200

Francois,

As long as one adheres to the escaping rules, it is perfectly valid to use # 
in URIs. The UA should not attempt any interpretation, but simply 
escape-and-pass anything the user dials.

The UA user interface can be such that '#' means end-of-input (ie <enter>), 
but it is also valid on the wire (when escaped)

Regards,

jeroen

----- Original Message ----- 
From: "Francois Audet" <[email-masked]>
To: "Juha Heinanen" <[email-masked]>
Cc: "Jesske, R" <[email-masked]>; <[email-masked]>; "Christer Holmberg 
(JO/LMF)" <[email-masked]>
Sent: Saturday, September 30, 2006 1:25 AM
Subject: RE: [Sip] Escaping rules of SIP-URI userpart

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 29 Sep 2006 19:10:28 -0500

It's a valid URI, yes, not necessarily a valid phone number.

Certainly not a valid global phone number.

The specific example mentioned (privacy=on) is very broken since
it really won't give you privacy at all. 

What bothers me with this thread is not that people want to use
strange characters in URIs.

What bothers me is that people want to use it to replicate
analog telephone keypad codes, the same way it was done back then,
in SIP. It was broken then, and it is even more broken now that
addresses
are supposed to be global.

> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Friday, September 29, 2006 4:56 PM
> To: Audet, Francois (SC100:3055); Juha Heinanen
> Cc: Jesske, R; [email-masked]; Christer Holmberg (JO/LMF)
> As long as one adheres to the escaping rules, it is perfectly 
> valid to use # in URIs. The UA should not attempt any 
> interpretation, but simply escape-and-pass anything the user dials.
> 
> The UA user interface can be such that '#' means end-of-input 
> (ie <enter>), but it is also valid on the wire (when escaped)
> 
> Regards,
> 
> jeroen
> 
> Cc: "Jesske, R" <[email-masked]>; <[email-masked]>; 
> "Christer Holmberg (JO/LMF)" <[email-masked]>
> should be  > 
> > translatable by the phone to a real URI that actually means  > 
> > something.
> >
> of phone 
> > there from the SIP phone, which cannot have a clue of various PSTN 
> > dial string conventions.  or can you explain what kind of magic 
> > translation nortel SIP phones do when user dial #31# followed by a 
> > phone number?
> 
> I'm saying doing what you are proposing, i.e., using # in a 
> phone number ON THE WIRE (I.e., in a URI), is an extremely 
> bad idea that we shouldn't attempt to do in SIP. And it won't 
> work except in isolated proprietary implementations.
> 
> In the example you gave (I'm hearing that some network 
> operator is using this for privacy).
> 
> What you need to do is intercept the digit pattern in the 
> phone, make the call to the destination without the 
> proprietary digits, and then mark your From header as 
> [email-masked].
> 
> To do it your way would MANDATE a B2BUA since my proxy would 
> have to remove the From and replace it (making it a B2BUA). 
> And it would magically have to understand all the dialling 
> plans in the universe.
> 
> So publishing a URI with a # means most people won't be able 
> to reach it. #31# means absolutely nothing to me in North 
> America. If I try to call you with this, it just won't work.
>

---

From: [email-masked]
Date: Fri, 29 Sep 2006 21:39:52 -0400

From: Juha Heinanen <[email-masked]>

I don't know whether it's worth doing, but it certainly is possible to
have the UA recognize certain dial strings and do something useful
based on that.  For example, the default sipX configuration uses
*78xxx for call pick-up on extension xxx.  Generally, the phones don't
know this, and the sipX proxy/redirector handles the machinery for
turning this INVITE into an INVITE-with-Replaces to perform the
pick-up operation.  But the phone could be programmed to know that *78
is the pick-up prefix, and perform the pick-up operation itself.

Dale