Subject: RE: [Sip] SIPIT Interop problem with ;user=phone

From: "Christer Holmberg (SE/LMF)" <[email-masked]>
Date: Fri, 22 Aug 2003 19:47:25 +0200

Hi,

My understanding (I think it's also written in the spec) is that telephone-describer is defined as in RFC2806 (TEL-URL spec). 

So, IF user=phone does indicate that the userpart must be according to the telephone-subscriber syntax (as defined in RFC2806), local numbers would need to have the phone-context parameter etc (see separate discussion on TEL-URL and local numbers). So:

sip:[email-masked];user=phone

...would not be valid, but:

sip:123;phone-context=[email-masked];user=phone

...would. The userpart would have to be a "global number" (as defined in RFC2806) not having to include the phone-context parameter. So:

sip:[email-masked];user=phone

...would be valid.

Regards,

Christer Holmberg
Ericsson Finland

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: 22. elokuuta 2003 19:47
> To: Conroy, Lawrence (SMTP); Gordon Ledgard; Robert Sparks
> Cc: [email-masked]
> Subject: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> Hi folks,
> can you explain a bit more in detail to a dumb bellhead what
> you mean with "telephone subsciber"?
>  
> Do you mean a subscriber number or a dialing string?
> Considering the funny dialing strings invented all over the
> place with access code for cross tunks like 1010 and **747..
>  
> I would prefer
> "if ';user=phone' is included, then the userpart MUST be formatted 
> (interpreted?) as a dialing string or phone number"
>  
> Any assumptions
> that a "PBX" chooses to make on what THAT implies is it's own 
> business.
> 
> Note: it is also assumed that the "PBX" may modify the userinfo
> 
> regards
> Richard
> 
> 
> 	-----Ursprüngliche Nachricht----- 
> 	Von: Conroy, Lawrence (SMTP) [mailto:[email-masked]] 
> 	Gesendet: Fr 22.08.2003 16:56 
> 	An: Gordon Ledgard; 'Robert Sparks' 
> 	Cc: [email-masked]' 
> 	Betreff: RE: [Sip] SIPIT Interop problem with ;user=phone
> 	
> 	
> 
> 	Hi Folks,
> 	    My vote's for exactly the statement that Robert proposes;
> 	"if ';user=phone' is included, then the userpart MUST 
> be formatted as
> 	a telephone-subscriber"
> 	
> 	Note that:
> 	At 10:10 am -0400 22/8/03, Robert Sparks wrote:
> 	>In fact, all the specification says is
> 	>that if the userinfo portion is formatted as a 
> telephone-subscriber
> 	>then the URI SHOULD also contain ;user=phone.
> 	the quoted statement is not the same as the above proposal.
> 	
> 	This proposal does *NOT* mean that any userpart that is 
> numerical
> 	MUST have this parameter appended - it says nothing of this.
> 	
> 	I see this parameter, where present, as an assertion that the
> 	userpart can be treated as a telephone-subscriber. Any 
> assumptions
> 	that a PBX chooses to make on what THAT implies is it's 
> own business.
> 	
> 	The proposal doesn't mean that a PBX needs to add the 
> parameter if it
> 	doesn't want to do this. The quoted SHOULD strength 
> means it can dodge
> 	that one if it has good reason.
> 	
> 	[From dim recollection, wasn't this one added originally to deal
> 	  with Compuserve numerical addresses vs. phone 
> numbers? Long ago
> 	  in a land far away...]
> 	
> 	In summary, I'm happy with this proposal
> 	
> 	all the best,
> 	   Lawrence
> 	
> 	At 10:29 am -0400 22/8/03, Gordon Ledgard wrote:
> 	>Hi. Robert Sparks asked....
> 	>  >>    I've seen a few interoperability failures at 
> SIPIT 13 revolving
> 	>>>     around the use of ;user=phone in sip URIs.
> 	>
> 	>>>     We have some implementations assuming that the 
> presence of ;user=phone
> 	>>>     means that the first part of the userinfo 
> portion of the URI MUST
> 	>>>     be formatted as a telephone-subscriber. Asking 
> around, I've found
> 	>>>     that many people believe this is the case, but 
> the spec does not
> 	>>>     support this claim. In fact, all the 
> specification says is
> 	>>>     that if the userinfo portion is formatted as a 
> telephone-subscriber
> 	>>>     then the URI SHOULD also contain ;user=phone.
> 	>
> 	>
> 	>My take on this would be to ask a further question.. What other
> 	>semantics do people expect "user=phone" to infer? Are they
> 	>making some other assumptions about the device based on this
> 	>parameter?
> 	>
> 	>If the answer is that people are using "user=phone" simply as a
> 	>shortcut to conclude that the user part is a phone 
> number to speed
> 	>up parsing and look-up, then the
> 	>
> 	>      " ;user=phone is present in a URI then the userinfo part
> 	>        MUST be formatted as a telephone-subscriber. "
> 	>
> 	>statement can stand.
> 	>
> 	>Having said that, this leads to a bunch of issues with 
> PBX sorts of
> 	>applications that need to map a 10 or 11 digit 
> telephone number into
> 	>a local extension, and vicey versey. The proxies, 
> B2BUAs or, or service
> 	>platforms would need to insert and yank the 
> ;"user=phone" parameter
> 	>on and off based on when the call entered or left the 
> local domain.
> 	>On top of that, these agents would need to understand the other
> 	>semantics being infered by "user=phone" in order to do 
> this properly,
> 	>which may well be impossible.
> 	>
> 	>In that case, the language of the spec ought to be 
> even more strict,
> 	>and say " "user=phone" means that the user part is a 
> phone number, and
> 	>no other assumtions about the device can be made.." or 
> words to that
> 	>effect. Which leads to the question... why have it? 
> Just parse it.
> 	
> 	
> 	--
> 	
> --------------------------------------------------------------
> ---------
> 	Roke Manor Research    : This information is provided 
> "as is" and is not
> 	<mailto:[email-masked]>: intended to create any 
> contractual or legal
> 	<tel:+441794833666>    : relationship.
> 	
> 	_______________________________________________
> 	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
> 	
> 
> J*fj)b	bm᩶?> 0o'~ffX)t"8bX묶+DYׯzZ)	ayq+y">-%R.Wz{h,rᯉny۟zbʢ{(˫	
> *T"䦘'~~ࠊ{^hgᯧ'ᬶbqbz
> 

_______________________________________________
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: "Christer Holmberg (SE/LMF)" <[email-masked]>
Date: Fri, 22 Aug 2003 20:22:55 +0200

Hi,

No matter if we remove it or not, I still think we should have a defined way on how to send telephone numbers in SIP-URIs, not to cause interop problems with devices using them.

For example, let's say that a node maps between TEL-URL and SIP-URI. The TEL-URL may contain "visual separators", which will also be inserted in the SIP-URI. Now, the node receiving the SIP-URI should also treat those a visual separators. But, without the user=phone parameter (or any other indicator), how will the receiving node know if those visual separator characters are visual separators, or valid pieces of the userpart.

Regards,

Christer Holmberg
Ericsson Finland

> From: Adam Roach [mailto:[email-masked]]
> Sent: 22. elokuuta 2003 21:05
> To: 'Gordon Ledgard'; 'Dean Willis'; Robert Sparks; [email-masked]
> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> I agree with Dean and Gordon. The semantics of "user=phone"
> have always eluded me. Unless we invest considerable effort
> in defining the precise meaning of this parameter, it would
> appear that it is doing more harm than good.
> 
> /a
> 
> > From: Gordon Ledgard [mailto:[email-masked]]
> > Sent: Friday, August 22, 2003 12:56
> > To: 'Dean Willis'; 'Robert Sparks'; [email-masked]
> > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> > 
> > 
> > 
> > I'm rather inclined to agree with Dean. 
> > 
> > I think the parameter amounts to a cheap trick for the sake of
> > fixing what amounts to an archaic database problem... Is the 
> > user in some
> > IP network domain, or does this call need to be forwarded to some
> > phone network gateway? And as he points out, it does so poorly.
> > 
> > Gordon
> > 
> > 
> > 
> > 
> > From: Dean Willis [mailto:[email-masked]]
> > Sent: Friday, August 22, 2003 12:45 PM
> > To: 'Robert Sparks'; [email-masked]
> > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> > 
> > 
> > 
> > > A companion question is should a UA arbitrarily hang 
> > > ;user=phone off a digit string it collects from its user, or 
> > > should it 
> > > transform that string into a telephone-subscriber 
> formatted number?
> > > 
> > > Both questions have clear answers if we explicitly add that
> > > if ;user=phone is present in a URI then the userinfo part
> > > MUST be formatted as a telephone-subscriber. Would anyone 
> > > object to adding this requirement?
> > 
> > The problem is that the syntax of telephone-subscriber 
> > doesn't actually
> > allow conveying all sorts of stuff that one might actually 
> > want to use a
> > digit strings in private dialing networks that actually talk 
> > to phones.
> > 
> > My suggestion is to deprecate user=phone entirely. It's a 
> > silly hack that,
> > as far as I can tell, just complicates implementations and 
> > URI comparison
> > with little actual value in return.
> > 
> > --
> > Dean
> > 
> >

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 22 Aug 2003 18:47:20 +0200

Hi folks,

I would prefer
 
Any assumptions
that a "PBX" chooses to make on what THAT implies is it's own business.

regards
Richard

	-----Ursprüngliche Nachricht----- 
	Von: Conroy, Lawrence (SMTP) [mailto:[email-masked]] 
	Gesendet: Fr 22.08.2003 16:56 
	An: Gordon Ledgard; 'Robert Sparks' 
	Cc: [email-masked]' 
	Betreff: RE: [Sip] SIPIT Interop problem with ;user=phone

	Hi Folks,
	    My vote's for exactly the statement that Robert proposes;
	"if ';user=phone' is included, then the userpart MUST be formatted as
	a telephone-subscriber"
	
	Note that:
	At 10:10 am -0400 22/8/03, Robert Sparks wrote:
	>that if the userinfo portion is formatted as a telephone-subscriber
	
	This proposal does *NOT* mean that any userpart that is numerical
	MUST have this parameter appended - it says nothing of this.
	
	I see this parameter, where present, as an assertion that the
	userpart can be treated as a telephone-subscriber. Any assumptions
	that a PBX chooses to make on what THAT implies is it's own business.
	
	The proposal doesn't mean that a PBX needs to add the parameter if it
	doesn't want to do this. The quoted SHOULD strength means it can dodge
	that one if it has good reason.
	
	[From dim recollection, wasn't this one added originally to deal
	  with Compuserve numerical addresses vs. phone numbers? Long ago
	  in a land far away...]

	all the best,
	   Lawrence
	
	At 10:29 am -0400 22/8/03, Gordon Ledgard wrote:
	>  >>    I've seen a few interoperability failures at SIPIT 13 revolving
	>>>     We have some implementations assuming that the presence of ;user=phone
	>>>     means that the first part of the userinfo portion of the URI MUST
	>>>     be formatted as a telephone-subscriber. Asking around, I've found
	>>>     that many people believe this is the case, but the spec does not
	>>>     support this claim. In fact, all the specification says is
	>>>     that if the userinfo portion is formatted as a telephone-subscriber
	>shortcut to conclude that the user part is a phone number to speed
	>Having said that, this leads to a bunch of issues with PBX sorts of
	>applications that need to map a 10 or 11 digit telephone number into
	>a local extension, and vicey versey. The proxies, B2BUAs or, or service
	>platforms would need to insert and yank the ;"user=phone" parameter
	>on and off based on when the call entered or left the local domain.
	>semantics being infered by "user=phone" in order to do this properly,
	>In that case, the language of the spec ought to be even more strict,
	>and say " "user=phone" means that the user part is a phone number, and
	>no other assumtions about the device can be made.." or words to that
	>effect. Which leads to the question... why have it? Just parse it.

	--
	-----------------------------------------------------------------------
	Roke Manor Research    : This information is provided "as is" and is not
	<mailto:[email-masked]>: intended to create any contractual or legal
	<tel:+441794833666>    : relationship.

J*fj)b�	b��m��?�0�'�~���f��f��X��)ߣ�"�8b�X��+��DYׯzZ)�����ay�+y">�-��%RǬ����W�z{h��,r�n���y۟���z�b�{(�˫����*T��"����'�~��~��{^��h�g���'����bq�b�z�*

---

From: William Marshall <[email-masked]>
Date: Mon, 25 Aug 2003 00:24:47 -0400 (EDT)

Rohan,

While I agree with your arguments about the distinction between tel: URIs
and sip: URIs, I have to disagree with the conclusion about ";user=phone".

There is certainly a difference between
	sip:[email-masked];user=phone
and	tel:foo				

The first is explicitely telling all servers other than bar.com to
keep their hands off the string "foo".  When the string "foo" appears
in a tel: URL, then all those transit servers can modify it, or route
the call to their own favorite gateway server; when the string "foo"
appears in a sip: URL, then the transit servers merely pass it 
unchanged to the explicitely named host/gateway.

What then is the point of ";user=phone"?  At bar.com, it may need the
hint to tell it that "foo" is to be interpreted as a phone number,
instead of an ancient Compuserve user-id.  Or maybe some users like
to be known by numbers.  Whatever.  It is up to bar.com to make the
decision, not the other servers in the network.  If bar.com doesn't
need the hint, it should be free to ignore any ";user=XXX" parameter.

I shudder to think of all the nasty surprises that would result if 
all the transit servers could interpret the ";user=phone" to mean
they understand the semantics of the username.  They don't.  Only
the named host can do that.  As an example, a server in Europe might
change a leading + to "00"; then when the request reached a server in
the US the call would complete to a long-distance operator; not at
all the intent of the originator.

I'm not sure if private numbering plans have been brought up in this
discussion or not.  They can certainly be implemented by having a digit
string indistinguishable from a complete E.164 number in a sip URI,
addressed to a server that understands the numbering plan.  Servers
along the path might look at the string and claim it is illegal - like
an invalid country code or area code.  It would not be good to prevent 
this service.  Should this service then disallow ";user=phone" in the
URI?  How is the UAC to know the difference?  Only bar.com knows.

So while ";user=phone" may be useful in some cases, stating that the
user part MUST be a valid global-number or local-number with ;phone-context
parameter, is just inviting all those other proxies to muck with things
they have no business touching.  In whatever wording is decided to deal with
the interop issue, the intermediate servers (whether proxies or B2BUAs) 
MUST NOT touch or check the username of a sip URI, whether ";user=phone" 
is present or not.  

Bill Marshall
[email-masked]

-----original message-----
Date: Sun, 24 Aug 2003 08:27:15 -0700
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
Cc: Robert Sparks <[email-masked]>, <[email-masked]>
To: Cullen Jennings <[email-masked]>
From: Rohan Mahy <[email-masked]>

Hi Folks,

To tie Cullen's comments more concretely to the discussion, I have 
always interpreted the semantics of ;user=phone to mean that the user 
part has been converted from a tel URL but that someone wants this tel 
URL to be handled in the context of a particular SIP domain.

If a SIP UA just collects a string of digits "1234" (this is not a tel 
URL), slaps on the domain name of their proxy, and then sends these 
digits there without interpretation, then you just end up with an 
ordinary SIP URI (user=ip):

	sip:[email-masked]

however, I think it is much more useful for the UA to generate a tel 
URL here instead:

	tel:1234;phone-context=+14085551111

Note that both of these are correctly scoped.  tel:1234 is illegal, as 
should be sip:[email-masked];user=phone (IMO).

Why not deprecate ;user=phone entirely?  Aside from backwards 
compatibility, there is actually a very good reason. Since tel: URIs 
don't have a domain portion, there is no way for me to send a tel URL 
through a loose-routed service and still convey which domain I would 
like the tel URI to be handled in.

So lets say that I send this INVITE

INVITE tel:+14085268570 SIP/2.0
Route: <sip:transcoders.org;lr>
...

transcoders.org will either reject the request or send it to whatever 
PSTN gateway it feels like using.  I would like to the INVITE to go to 
a specific provider out of a list of several of these, but I do not 
want to negotiate the specific user-part naming convention with each 
one:

INVITE sip:[email-masked];user=phone SIP/2.0
Route: <sip:transcoders.org;lr>

Likewise I can use SIPS to go to a different provider:

INVITE sips:[email-masked];user=phone SIP/2.0

Continuing on in this vein, say I REFER Jiri (in Europe) to call Adam's 
cell phone (in Texas).  It would be much nicer to provide this Refer-To 
URI:

sips:[email-masked];user=phone   (a tel URL 
addressed to a particular SIP UA)

instead of:

tel:+19991234567

(since Jiri may need to discover such a gateway, or be billed for an 
International PSTN call when he has a perfectly good Internet he can 
use instead for the "expensive" part of the call).

So, I think the ;user=phone is in fact very useful (even if only as a 
standardized convention).  If it is used at all I think the user part 
MUST be a valid global-number or local-number with ;phone-context 
paramter, if user=phone is in the SIP URI.

thanks,
-rohan

On Friday, August 22, 2003, at 01:09 PM, Cullen Jennings wrote:

>
> More than one person has suggested that we should use tel URL (ala 
> 2806bis
> not 2806) for telephone numbers, local PBX numbers, 800 etc and we 
> should
> use sip for sip AORs. This clears up an incredible amount of weirdly
> specified comparison issues that are poorly implemented. At first 
> glance it
> looks like it would cause lots of backwards compatibility problems but 
> it
> might be worth looking at how bad they would be. The current situation 
> has a
> lot of problems that are somewhat swept under the rug.
>
> One comment I would like to add is that in the SIP messages that flow 
> over
> the wire, we do need both telephone number and SIP AOR. We do not need
> dialed digits instructions - the user interfaces of UA might use these 
> but
> the protocol does not need them.
>
> Cullen
>
>
> On 8/22/03 7:10, "Robert Sparks" <[email-masked]> wrote:
>
>> So, is this an oversight? Are we allowing URIs with ;user=phone
>> but a non telephone-subscriber formatted userinfo part on purpose?
>>
>> Those with code making the above assumption fail to interoperate
>> with devices that gather an arbitrary number of digits and
>> just slap ;user=phone in the URI when creating a request.
>> For example:
>>
>> <sip:[email-masked];user=phone>
>>
>> They reject this as a malformed URI since 15 doesn't parse per
>> telephone-subscriber. Is this being too strict? Should they
>> try to interpret this as a "number that has meaning in their
>> local scope"? It certainly isn't safe to pretend the ;user=phone
>> wasn't there and try to interpret "15" as a username. What's
>> the right thing for them to do?
>>
>> A companion question is should a UA arbitrarily hang ;user=phone
>> off a digit string it collects from its user, or should it
>> transform that string into a telephone-subscriber formatted
>> number?
>>
>> RjS

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 25 Aug 2003 09:04:51 +0200

Hi folks,
just for my understanding:

> The first is explicitely telling all servers other than 
> bar.com to keep their hands off the string "foo".  When the 
> string "foo" appears in a tel: URL, then all those transit 
> servers can modify it, or route the call to their own 
> favorite gateway server; when the string "foo" appears in a 
> sip: URL, then the transit servers merely pass it 

I thought that any server will take his hand off "foo" anyway
if it is not "bar.com".
Am I missing something?
Richard

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Aug 2003 10:30:29 -0500

[Changing thread back to original title]

Rosen, Brian [mailto:[email-masked]] writes:

> user=phone, at the moment, means "this is a dial string".

I think we have strong evidence in this discussion that
not everyone agrees with this statement. Why? Because
"user=phone" is somewhat underspecified.

That said, the current normative language in 3261 would
seem to support Rohan's interpretation (albeit in a
somewhat muddy way):

         If the user string contains a telephone number
         formatted as a telephone-subscriber, the user
         parameter value "phone" SHOULD be present.

RFC 3261 then cites RFC 2806 as the source for the
"telephone-subscriber" syntax. Presumably, the next
RFC describing SIP will update its reference to reflect
the output of 2806bis.

Combined with the text in 19.1.2 and 19.1.6, RFC 3261
certainly seems to indicate that "user=phone" is intended
be transformable to a tel: URI by reversing the procedures
in 19.1.2. So, as you point out:

> It used to be that you could do the same in a tel uri, but we
> "fixed" that.

...meaning that, if we were to do nothing but rev 3261 with
updated references, using bare, unscoped digit strings with
"user=phone" would automatically become deprecated.

> Until we have overwhelming deployment of end devices
> that translate dial strings to tel uris (PLEASE do not say
> E.164s or global identifier, they are not all global numbers
> after translation)

I think that's what "phone-context" is supposed to convey.

> we need to leave user=phone as the way to send a dial 
> string.

As I said in my original post on this topic, unless someone
wants to invest the effort required to definite precise
semantics of "user=phone", it needs to be deprecated. The
current situation is causing demonstrable interop problems.

You sound like you're pretty motivated to fix the problem.
Perhaps you can put together an i-d that clarifies the
precise meaning of "user=phone".

/a

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 26 Aug 2003 08:28:51 -0700

On Tuesday, August 26, 2003, at 04:59 AM, <[email-masked]> 
wrote:

> Why isn't this the problem of tel: URI?

I think user=phone is just a useful standardized convention to say to 
the SIP server in the domain part that "the user part of this SIP/SIPS 
URI is an encoded tel URL".

> I dare to make the suggestion that the tel URI itself can have a 
> parameter called "domain" or something similar to accommodate the 
> scenario Rohan presents?

I think you loose a lot of flexibility there.  For example the 
distinction between using SIP and SIPS and all the NAPTR/SRV lookups we 
get with SIP.

> We can then deprecate user=phone and any use of telephone-subscriber 
> in a sip URI. SIP URI then always carries a SIP URI.
> Thanks,
> Hisham
>
>> From: ext Rohan Mahy [mailto:[email-masked]]
>> Sent: Sunday, August 24, 2003 6:27 PM
>> To: Cullen Jennings
>> Cc: Robert Sparks; [email-masked]

---

From: [email-masked]
Date: Tue, 26 Aug 2003 16:22:14 +0300

I dare to make the suggestion that the tel URI itself can have a parameter called "domain" or something similar to accommodate the scenario Rohan presents?

We can then deprecate user=phone and any use of telephone-subscriber in a sip URI. SIP URI then always carries a SIP URI.

Thanks,
Hisham

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 27 Aug 2003 09:49:07 +0200

To my knowledge the Tel: URI (in rfc1806bis) has the
parameter  ;phone-context= 

Local numbers MUST have a phone context, either e.g. =+1800 or
=foo.bar.com 

This is explained lenghty in section 5.1.4

Richard

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, August 26, 2003 2:00 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> I dare to make the suggestion that the tel URI itself can 
> have a parameter called "domain" or something similar to 
> accommodate the scenario Rohan presents?
> 
> We can then deprecate user=phone and any use of 
> telephone-subscriber in a sip URI. SIP URI then always 
> carries a SIP URI.
> 
> Thanks,
> Hisham 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>

---

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Wed, 27 Aug 2003 11:45:35 -0400

Inline [RRR]

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: Wednesday, August 27, 2003 9:28 AM
To: Roy, Radhika R, ALABS; Rosen, Brian; William Marshall; [email-masked]
Cc: [email-masked]
Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone

Inline [Sta]

> From: Roy, Radhika R, ALABS [mailto:[email-masked]] 
> Sent: Wednesday, August 27, 2003 3:17 PM
> To: Rosen, Brian; William Marshall; [email-masked]
> Cc: [email-masked]; Stastny Richard
> Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> Inline [RRR]
> 
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, August 26, 2003 8:23 AM
> To: 'William Marshall'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> ....
> 
> This means there is no global understanding of the user part.
> 
> [RRR] Yes, this is the key. So, there will not be any 
> universal interoperability.

[Sta] ??why not?? Do I need to look at the user part in e-mail?

[RRR] The interpretation of the user part, I think, is a local matter,
and does not need to be universal.

Richard
> ....
> Brian

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 27 Aug 2003 10:11:05 +0200

[inline]

> Sent: Tuesday, August 26, 2003 2:23 PM
> Well, in many real systems there are several proxies that 
> understand the local domain.  For example, 
> pitt.sip.marconi.com and coventry.sip.marconi.com may 
> understand the marconi.com dialing plan.  Often, a phone is 
> given a default domain. Any URL presented to it (such as a 
> dial string) that does not have an explicit domain has the 
> default domain appended to it. So, as long as the proxy that 
> handles the expansion understands the dial plan in the 
> specified domain, then it can process it. I think that's 
> pretty explicit.
> 
> At the moment, we don't have any specification for a dial 
> string, and while we might evolve one in the configuration 
> work, I would not propose to specify how a dialstring is 
> interpretted. This means there is no global understanding of 
> the user part.

Yes, because there is no global dialing plan, only national, local and
private.
Richard

> > From: William Marshall [mailto:[email-masked]]
> > Sent: Tuesday, August 26, 2003 7:22 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone
> > 
> > 
> > Cullen wrote (entire message quoted below):
> > > sip:[email-masked] means send it to foo.com and foo will
> > figure it out.
> > > 
> > > sip:[email-masked];user=phone means send to to foo.com and
> > foo will figure it out.
> > 
> > I think the above statement is exactly right.  As Richard
> > Stastny wrote
> > > I thought that any server will take his hand off "foo" 
> anyway if it 
> > > is not "bar.com".
> > 
> > But I get somewhat worried when I see comments like that
> > contained in a
> > message from Brian Rosen yesterday (entire message quoted below),
> > > If you send sip:<dialstring>@<host>;user=phone, then <host>,
> > > or at least a proxy that understands the <host> dialing plan, 
> > > does the translation.  That may or may not be the first hop proxy.
> > 
> > ***or at least a proxy that understands the <host> dialing plan****
> > 
> > If the ";user=phone" requires a strict format and global 
> understanding 
> > of the username of the sip: URI, then everyone can claim to 
> be a proxy 
> > that understands the <host> dialing plan.  This is wrong.
> > 
> > It should instead read:
> >    If you send sip:<dialstring>@<host>;user=phone, then <host>
> >    does the translation.  That may or may not be the first 
> hop proxy.
> > 
> > Bill Marshall
> > [email-masked]
> > 
> > -----original messages-----
> > Date: Mon, 25 Aug 2003 09:04:51 +0200
> > From: "Stastny Richard" <[email-masked]>
> > To: "William Marshall" <[email-masked]>, <[email-masked]>
> > Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
> > 
> > Hi folks,
> > I thought that any server will take his hand off "foo" 
> anyway if it is 
> > not "bar.com". Am I missing something?
> > Richard
> > 
> > ----------
> > From: "Rosen, Brian" <[email-masked]>
> > To: "Rosen, Brian" <[email-masked]>,
> >    "'Henning Schulzrinne'" <[email-masked]>,
> >    "Conroy, Lawrence (SMTP)" <[email-masked]>
> > Cc: Adam Roach <[email-masked]>, [email-masked],
> >    Richard <[email-masked]>
> > Subject: RE: Warning about dial plan assumptions (was RE: AW:
> > [Sip] SIPIT 
> > 	 Inte rop  problem with ;user=phone)
> > Date: Mon, 25 Aug 2003 11:10:25 -0400
> > 
> > Someone just pointed out to me that there could be confusion on who 
> > translates a dial string to a routable number. If you send 
> > sip:<dialstring>@<host>;user=phone, then <host>, or at 
> least a proxy 
> > that understands the <host> dialing plan, does the 
> translation.  That 
> > may or may not be the first hop proxy.
> > 
> > Most phones that I know have <host> configured; you don't 
> type it. If 
> > you did, and it wasn't your local proxy, then you better understand 
> > how whatever you typed interprets your dial string, and your local 
> > proxy better not muck with it.
> > 
> > Brian
> > 
> > ----------
> > Date: Mon, 25 Aug 2003 11:48:36 -0700
> > Subject: Re: AW: [Sip] SIPIT  Interop  problem with ;user=phone
> > From: Cullen Jennings <[email-masked]>
> > To: <[email-masked]>
> > 
> > sip:[email-masked] means send it to foo.com and foo will 
> figure it out.
> > 
> > sip:[email-masked];user=phone means send to to foo.com and foo
> > will figure it
> > out. 
> > 
> > Right now it is totally random if the UA puts in the
> > user=phone or not and
> > the proxies (as far as I can tell) mostly ignore it. I'm 
> > having a hard time
> > figuring out what the requirement is for this extra 1 bit of 
> > information
> > that currently has no semantic meaning. There is a certain amount of
> > operational experience that indicates this flag is not needed.
> > 
> > I think the whole thing is bogus unless someone can clearly state a 
> > requirement that says why the proxy might need to know some 
> extra bit 
> > of information and clearly says how the UA would set this bit of
> > information
> > based on something the user entered on the UA.
> > 
> > Defining something that all UAs will set to the same value or
> > all proxies
> > will ignore is useless.
> > 
> > Cullen
> > 
>

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 27 Aug 2003 10:08:42 +0200

[below]

> Sent: Tuesday, August 26, 2003 2:34 PM
> To: 'Cullen Jennings'; [email-masked]
> We might be weird, but lack of user=phone indicates to our 
> proxy that we should look up the user part in our registered 
> user list. Including user=phone means we pass the user string 
> to our gateway processing section that interprets a set of 
> rules to expand the user name into a url.  We use this 
> capability in many interesting ways.  For example, you can 
> force routing of a call to a particular gateway (if site 
> policy permits it).  Typically, to do this we put some alpha 
> prefix on the number. Thus: 
> sip:[email-masked];user=phone means that the call 
> will be passed to the Pittsburgh PBX gateway calling extension 4826.  
> You could get to the same phone by dialing 
> sip:[email-masked];user=phone, but that may route a different 
> way (for example, it could be routed to a local gateway, to the 
> local PBX, and then over a tie line between the local PBX and the 
> Pittsburgh PBX).  We do this by creating rules in the ruleset 
> that match the pitpbx prefix.  We have a matching regexp and 
> a replacement regexp, so that a general purpose substitution 
> is possible (the actual expansion of the example would be 
> sip:[email-masked]).
> 
> If you tried calling sip:pitpbx4826 without the user=phone, 
> we would try to find a user named pitbbx4826 in our 
> registrar's database.

And you expect a user to dial all this?
This is even worse than the first Subscriber Trunk Dialing (STD) in UK
in 1950 where the users had to dial origination dependent Trunk Codes
before Trunk Auto and Registers where invented ;-)

Back to the future ...

Richard

> > From: Cullen Jennings [mailto:[email-masked]]
> > Sent: Monday, August 25, 2003 2:49 PM
> > To: [email-masked]
> current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 27 Aug 2003 14:59:11 -0400

Some gateways know how to convert a dial string to a phone number.
Most don't.
If you send a gateway that does a dial string (denoted by user=phone),
then you are telling the gateway to invoke its dial string processing.

Some proxies know how to convert a dial string to a phone number.
Some don't
If you send a proxy that does know a dial string (denoted by user=phone)
then you are telling the proxy to invoke its dial string processing.

If the gateway doesn't have dial string processing, and you send it
user=phone, it could complain, or it could try to guess that the user
part is a phone number and call it.  That may or may not work.

If the proxy doesn't have dial string processing, and you send it
user=phone, it could complain, or it could try to guess that the
user part is a phone number and route it as best it can.  That may
or may not work.

Now we get to the part I'm not sure of.
If you send a proxy a tel uri, it better be routable either globally or
within the specified context and it's definately an error if it is not.
It may have to translate to a SIP URI.  It probably needs to mark
the SIP URI that it was a translated tel uri, which might be user=phone,
but I think we need something new (user=FormerlyWasATelUri).

If you send a gateway a tel uri, then it better be dialable from
that gateway.  I don't think this will be common (that is, I think
a proxy will translate a tel uri to a sip uri and route it before it
arrives at a gateway).

If you send a proxy a numeric username, and you don't specify user=phone,
and you don't specify something new, I think correct behavior should
be to try to FIRST look up the number in the registration database.
If you don't get a hit, you could try to route the number using your
gateway processing rules (TRIP for example).

If you send a proxy a numeric username, and you specify something new
(like user=FormerlyWasAtelUri), then we know that we want the proxy to
route it, as translation has already been done.

If you send a gateway a numeric username, and you don't specify user=phone
OR you specify user=FormerlyWasAtelURI, then it should treat it as a
dialable number.

> Sent: Wednesday, August 27, 2003 1:43 PM
> To: Rosen, Brian
> Cc: 'Cullen Jennings'; [email-masked]
> brian suggested about user=phone:
> > I think it should be used to denote that the user part is a 
> dial string.
> 
> Assume a gateway gets a SIP INVITE that does NOT have a user=phone
> parameter, but the host-part of the request-URI matches the
> area-of-responsibility for that gateway (for example, it's hostname).
> 
> Should it:
> 
> 1) Respond with a 404 (or related code), because it's a GATEWAY and it
> MUST receive a dial-string as the user-part of a SIP(S) request-URI.
> 
> 2) Try to convert the user part) into a phone number anyhow.
> 
> If case 1, I submit that we just added a lot of complexity to other
> people's forwarding tables, and I don't think we got anything 
> out of the
> effort.
> 
> If case 2, I submit that the user=phone parameter achieved nothing and
> might as well be deprecated.
> 
> 
> --
> Dean
>

---

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Wed, 27 Aug 2003 09:17:08 -0400

Inline [RRR]

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, August 26, 2003 8:23 AM
To: 'William Marshall'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone

....

[RRR] Yes, this is the key. So, there will not be any universal interoperability.

....

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 27 Aug 2003 08:18:19 -0400

There is a dialing plan, that has a routing ruleset.
If you send a tel uri with the local context, or
a sip uri with user=phone, we will apply that ruleset to
the number -- it isn't really limited to be a number.
The prefix is used when someone wants to force routing
to something.  We have administrative controls that can
limit this.  It turns out to be pretty usefull in
some circumstances.

The only relevance to this discussion remains that we
can't use a hint like "it's all digits" to decide if
we are to use a dialing plan or not.  We use user=phone.

Brian

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Wednesday, August 27, 2003 1:28 AM
> To: Rosen, Brian
> Rosen, Brian writes:
>  > call to a particular gateway (if site policy permits it).  
> Typically,
>  > to do this we put some alpha prefix on the number. Thus:
>  > Pittsburgh PBX).  
> why can't your proxy check if the number begins with 300 and 
> then route
> the call the same way it now routes a pitpbx call?  who is 
> adding pitpbx
> in front of the number?
> 
> -- juha
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 27 Aug 2003 09:14:14 -0400

I'd prefer that we not go around saying that user=phone means
the user part is a tel uri.  We need to be able to handle that
circumstance for backwards compatibility, but we should be
encouraging implementors to use a tel uri when they have
a globally routable number, or a local number with a context.

There are other uses for user=phone that have been discussed here,
and I believe we need to keep it, but I would prefer that we don't
encourage its use when a tel uri would work.

Brian

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Tuesday, August 26, 2003 11:29 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 27 Aug 2003 15:28:11 +0200

Inline [Sta]

Richard

---

From: [email-masked]
Date: Wed, 27 Aug 2003 16:29:39 +0300

> Sent: Tuesday, August 26, 2003 6:29 PM
> To: Khartabil Hisham (NMP/Helsinki)

Richard pointed out that phone-context satisfies by suggestion. But to answer Rohan:

Under the informative text in 2806bis labeled "A Use of "tel" URIs with SIP (Informative)", it says:

"
             2.   The outbound proxy does not use the same phone
                  context, but can route to a proxy that handles this
                  phone context. This routing can be done via a lookup
                  table or the domain name of the phone context might be
                  set up to reflect the SIP domain name of a suitable
                  proxy. For example, a proxy may always route calls
                  with tel URIs like

                  tel:1234;phone-context=munich.example.com

                  to the SIP proxy located at munich.example.com." 

So, how does the proxy route this message to munich.example.com (perhaps this is a question for Henning)?

Why can't this be used for your scenario of routing the sip message to provider1.com?

Regards,
Hisham

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 27 Aug 2003 08:19:33 -0400

Actually, it's almost always in something akin to a speed dial.
We use it, for example, to force routing to the home gateway
to a pbx when we are roaming, and the user is trying to access
his voicemail box, rather than use the visiting routing rules.

Test techs also appreciate it.

Brian

> Sent: Wednesday, August 27, 2003 4:09 AM
> To: Rosen, Brian; Cullen Jennings; [email-masked]

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 27 Aug 2003 17:09:38 -0700

On Monday, August 25, 2003, at 08:49 AM, Rosen, Brian wrote:

> I can do that.
> Anyone want to argue that user=phone should not be interpretted
> as a dial string?

yes.  unqualified dial strings are dangerous, and it is trivial to 
qualify them.  Instead, the user=phone parameter should indicate a 
valid tel URI is in the userpart (which can *contain* a dial string).

It is trivial to qualify a dial string and turn it into a tel URI.  If 
you want to send a dial string with the user=phone parameter, then 
please spend the extra line of code to add the ;phone-context parameter 
for heaven's sake.

> I understand why reading the tea leaves of the
> current RFCs leads to confusion, but I think there is good reason
> to send dial strings sometimes

certainly, but I don't believe there is any reason why these dial 
strings should be sent without a phone-context parameter.

> , and I don't think there is any
> other reason for user=phone.

sending a fully qualified e164 address strikes me as a pretty good 
reason.

>   I know that some phones DO have
> internal translations, and they do send user=phone with a global
> number, but that's a valid dial string, no?

no.  a global number is not a dial string.  a *dial string* has no 
globally scoped semantics.  the tel URI does. a global number can be 
*converted* to a dial string in a particular context (at a specific 
gateway).

>   I'd propose to
> deprecate that (use a tel uri), but allow it for backwards
> compatibility

i'm proposing the opposite. don't ever send unqualified dial strings 
with ;user=phone.  always use the tel URL format instead.

thanks,
-rohan

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 28 Aug 2003 09:52:23 +0200

Folks,

may I add some more clarification to what Rohan said in his responses:

I consider ;user=phone useless, because it does not tell you anything
about the dial string or number

This means it can be used feasible only at the first proxy knowing
exactly what the UA context is. Since this proxy knows this anyway, it
does not
need ;user=phone at all. Normally this is contained in a sip: URI with
the
hostpart addressing exactly this proxy anyway by default.

If you transmit this to another proxy or gateway, the other gateway may
have no
idea what you mean, so you have to normalize the information anyway
(e.g.
by transforming the "dialstring" to an E.164 number eg
sip:[email-masked]
or tel:+xxx. Both of them EXACTLY define what you mean.

Using sip:[email-masked];user=phone does not tell you if this is a
private number, a local number or a national number 
OR if it is a dialstring. ID it is a dalstring, it may be in ANY
national or
even worse local or private context.

So either we add similar things like in the PSTN (e.g. Type of number
(TON)
or network address Indicator (NAI), but then you have to add also the 
;phone-context=+431 or vienna.at if you use a TON or NAI national or
subsciber number.

But for a global system this is useless, because nobody is able to deal
with all contexts anyway, so the natural way is to normalize dialstrings
or phone numbers at the first possible place knowing what the users
context
is (this is either the UA itself or the AUS where the user is sending
the dialstring
or phone number to) and use only fully qualified E.164 numbers
everywhere else.

The only possibility to keep a non-E.164 number is within a network and
in
this case the tel: URI using a local number with a phone-context already
exists.

So a UAS may translate a dialstring received from a UAC in the format
sip:[email-masked] either in sip:[email-masked]
or in a tel:17476691281;phone-context=sipphone.com

Remark: If by a freak event sipphone.com gets the NPA 747 really
assigned
as E.164 number, you may also use either sip:+17476691291 or
tel:+17476691291

best regards
Richard

> Sent: Thursday, August 28, 2003 2:10 AM
> To: Rosen, Brian
> Cc: 'Adam Roach'; [email-masked]
> >> As I said in my original post on this topic, unless 
> someone wants to 
> >> invest the effort required to definite precise semantics of 
> >> "user=phone", it needs to be deprecated. The current situation is 
> >> causing demonstrable interop problems.
> >>
> >> You sound like you're pretty motivated to fix the problem. Perhaps 
> >> you can put together an i-d that clarifies the precise meaning of 
> >> "user=phone".
> >
> > I can do that.
> >
> > Anyone want to argue that user=phone should not be 
> interpretted as a 
> > dial string?
> 
> > current RFCs leads to confusion, but I think there is good 
> reason to 
> > send dial strings sometimes
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 28 Aug 2003 09:41:40 -0400

Boy, are we all over the map.

I'm not sure there is any way to get consensus on this.

There are a couple of things we can get done however, so lets
start there.

Tel URIs explicitly MAY NOT be dial strings.  They can be 
phone numbers within a context, but not dial strings.
It's certainly the case that there is overlap in many dial plans
between "a phone number within a context" and a dial string,
but they are not the same thing.  In general, if you
have a SIP phone without a dial sting expansion mechanism
built in, it should not be sending tel uris.  If you do
have a phone with dialstring expansion, than I think you
SHOULD send a tel uri, and not send a sip uri with user=phone.
We know that there are phones out there that don't do this,
but could we agree that the above is where we SHOULD head?
For the moment, let's defer the discussion of whether
a sip phone without dialstring expansion sends any parameters
on the INVITE.

Gateways, I believe, should be generous in what they accept.
So if a gateway gets a tel uri, a sip uri with or without 
the user=phone parameter, and the phone number is within its 
area of responsibility, it should accept the INVITE and place 
the call.  Any objections?

Can we agree on what a sipphone should be prepared to accept?
Surely, it should accept a sip uri with a numeric username if
that is (one of) its AoR(s).  Again, being generous, it should 
accept such an INVITE with or without a user=phone.  Should
a phone accept a tel uri?  Is that a SHOULD or a MAY?

The next thing that might be easy to agree on is what a proxy
that translates a tel URI to the routed (or at least routable)
sip uri does.  Should it have add a parameter, and what should
that parameter be?  I had been thinking we should create a new
parameter for this purpose.  I note that we have had some
discussion on another thread that talked about marking a URI
that had been ENUM translated.  

I'll stop there.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 28 Aug 2003 09:58:40 -0400

> My goodness, that is different. While it is a very reasonable "user
> part", I would not have considered "pitpbx4826" a dial string, and my
> first hunch would be that it's simply invalid when combined with
> user=phone. (it probably isn't which means we DO have a spec clarity
> problem). I would have been much more likely to encode this as
> sip:[email-masked], which means to me "whatever 4826 means to
> pitpbx.marconi.com", which is what I think you wanted to express.
No, all the usernames within this system are within the local domain,
and it's not a good idea for anyone but the routing proxy to know which
host is the destination for a given username/phone number.
The proxy might translate [email-masked] to [email-masked],
but we don't hand out IP addresses, or even hostnames, of specific gateways.
pitpbx4826 means "extension 4826 on the gateway that supports that
extension on the Pitt PBX". Today, that could be pitpbx.marconi.com, but 
tomorrow it might be some other host.

> 
> It might be reasonable for proxy "marconi.com" to route (this is
> expressible in TRIP) all digit sequences starting with 300 to
> pitpbx.marconi.com, and potentially even strip off the 
> matched digits so
> there's no uncertainty at pitpbx. Going this way lets you 
> make a dynamic
> route-optimization decision at the proxy as to whether it 
> would be more
> efficient to route via PSTN. In any case, it lets one use
> [email-masked], again with no user=phone.
That's the normal routing mechanism, and indeed we could use 
TRIP for normal routing.  However, most of these routing decisions
are made on "least cost route" metrics.  The problem is that
sometimes, that is not the appropriate mechanism to use.

> 
> I think you've gone down a very different design path that requires a
> heck of a lot more work in setting up gateways and intelligence for
> string-manipulation in those gateways than might have been required by
> other design paths. It'll work, sort of, with the right equipment, but
> seems overly complex.
The gateways require no intelligence whatsoever.  The only intelligence
is expressed in a bunch of regexps on the proxy.  The gateways always
get a simple sip:xxxx@<hostname>.marconi.com;user=phone.  In the case
we are discussing, the marconi.com proxy matches [email-masked]
and translated that to [email-masked]

> 
> Maybe it's time to write a book about how to build
> usable/useful/maintainable SIP networks for the enterprise?
I agree
> 
> Remember: failures induced by convoluted implementations do not
> necessarily entail a design flaw in the components used in that
> implementation. Or, as I like to say, baroque is probably broken.
I don't think what we do is complex at all (we'll, I'll confess that
we have evolved our routing rule grammars quite a bit to avoid getting
things too complicated).

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 28 Aug 2003 14:15:13 -0400

> Citing an example inf RFC 2806:
> 
>      tel:0w003585551234567;phone-context=+3585551234
> 

From 2806bis
 Dial string: "Dial strings" are the actual numbers, symbols and
      pauses entered by a user to place a phone call. A dial-
      string is consumed by one or more network entities, and
      understood in the context of the configuration of these
      entities. It is used to generate a telephone number so that
      a call can be routed. Dial-strings may require pre-pended
      digits to handle local PBXs, and they may include post-dial
      DTMF signaling that could control an IVR or reach an
      extension. Dial strings are beyond the scope of this
      document. 

Therefore, you can no longer use your example, and a dial string
MUST be sent as a sip uri.  I think that it would be a good idea
to mark such dial strings as dial strings, but YMMV.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 28 Aug 2003 17:52:56 -0400

Yeah, we could do that, although there aren't many devices out
there who can handle a phone-context in a sip uri.  It's not an
exact match with the problem, because we're explicitly forcing
a route, rather than restricting to a context, but there is no
doubt we could get what we want from such a syntax.  

Really, the context is pitt.marconi.com.  If we specified
sip:4826;phone-context=pitt.marconi.com; user=phone
we would expect to use the regular routing rules, which would
normally be something that was least-cost.  The example used
3006826, which is the 7 digit number plan version of the same
thing (300 prefix is equivalent to pitt.marconi.com).

Making up a new set of contexts and using that to force routing
is a stretch, but it works.

I think our devices would actually allow us to put such a tel
uri under a softkey, so we probably could actually implement it.
We'd have to change the proxy some, but not much, as it's all
a string matching regexp thingy.  

Brian 

> Sent: Thursday, August 28, 2003 5:37 PM
> To: 'Rosen, Brian'; 'Dean Willis'
> Cc: [email-masked]
> Rosen, Brian [mailto:[email-masked]] wrote:
> 
> > No, all the usernames within this system are within the
> > local domain, and it's not a good idea for anyone but the
> > routing proxy to know which host is the destination for
> > a given username/phone number. The proxy might translate
> > [email-masked] to [email-masked], but we
> > don't hand out IP addresses, or even hostnames, of specific
> > gateways. pitpbx4826 means "extension 4826 on the gateway
> > that supports that extension on the Pitt PBX". Today, that
> > could be pitpbx.marconi.com, but tomorrow it might be some
> > other host.
> 
> Oh! So, what you *really* mean is:
> 
>   tel:4826;phone-context=pitpbx
> 
> Which, using the rules in 3261 today, can be transformed to:
> 
>   sip:4826;phone-context=[email-masked];user=phone
> 
> /a
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Aug 2003 16:36:35 -0500

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Aug 2003 16:30:14 -0500

> I'm not sure there is any way to get consensus on this.

I don't think there's a way to get *unanimity* on this.

I don't think you can even get an overwhelming majority
opinion.

However, if you count the number of people who have posted
on this thread and compare it with the number of people on
this thread who have said, "deprecate it", I think you'll 
find that we already have a very rough consensus.

/a

---

From: [email-masked]
Date: Fri, 29 Aug 2003 11:03:09 +0300

"

So, how does the proxy route this message to munich.example.com?

/Hisham

> From: ext Dean Willis [mailto:[email-masked]]
> Sent: Thursday, August 28, 2003 9:04 PM
> Cc: [email-masked]; [email-masked]; [email-masked]
> On Thu, 2003-08-28 at 03:43, [email-masked] wrote:
> > No one has been able to convince me why not to use a tel URI 
> > for dial strings and sip URI for pure sip users.
> > 
> > When a proxy receives a sip request with a sip request-uri 
> containing 
> > a domain it is responsible for, it looks up it s registration table 
> > and rejects the request with 404 if not found.
> 
> What if the call originator didn't KNOW that the request was going to
> end up on a gateway? Can the proxy send the request to a 
> gateway anyhow?
> 
> Proxies can reasonably do a LOT more than just registration based
> routing. The proxy in my office, for example, executes a user-supplied
> CPL script, which allows the specification of actions to take (like
> forwarding the call to my mobile phone) if there is no registration.
> 
> > When a proxy receives a sip request with a tel request-uri 
> without a phone-context, it forwards the request to its default GW.
> 
> or applies whatever other routing rules it would apply, for example
> prefix matching in TRIP.
> 
> > When a proxy receives a sip request with a tel request-uri 
> with a phone-context, it forwards the request to the proxy/GW 
> indicated by the phone-context.
> 
> Phone-context is NOT currently a globally routable thing. It provides,
> at best, a locally-meaningful hint about how one might proceed.
> 
> 
>    This URL places a voice call to the given number. The number format
>    is intended for local use: the first zero opens an outside 
> line, the
>    "w" character waits for a second dial tone, and the number already
>    has the international access code appended to it ("00"). 
> This kind of
>    phone number MUST NOT be used in an environment where all users of
>    this URL might not be able to successfully dial out by using this
>    number directly. However, this might be appropriate for pages in a
>    company intranet. The <area-specifier> which is present hints that
>    the number is usable only in an environment where the 
> local entity's
>    phone number starts with the given string (perhaps singling out a
>    company-wide block of telephone numbers).
> 
> > Why does a proxy need to translate a tel URI to a sip URI 
> before forwarding a request?
> 
> Because its routing table might tell it that the gateway to 
> handle that
> tel URI is remote, and the other SIP proxies between here and there
> might have different, even conflicting, routing policies for TEL URIs.
> 
> > I believe tel:12345;phone-context:example.com and 
> sip:[email-masked] can be the same or different users. Why 
> do we have to restrict them to be the same user?
> > 
> > Also, why do we need to represent 
> tel:12345;phone-context:example.com as 
> sip:[email-masked];user=phone ? what is the gain in this?
> 
> Because @example.com is probably globally routable (at least, we have
> well-documented resolution procedures), and 
> phone-context:example.com is
> probably not globally routable (we do NOT have well-documented
> resolution procedures).
> 
> --
> Dean
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 29 Aug 2003 11:17:03 -0400

It's all in what you are talking about.

SIP itself doesn't need such things, but we need to
transport such strings as part of an INVITE to a gateway
connected to the PSTN or a private DTMF based phone system.

We could invent a new mechanism, or redefine an 
existing mechanism, or do what we do now;
put it in the userpart of a sip uri.

We could argue about whether such a string should or
should not have user=phone :)

Brian

> Sent: Friday, August 29, 2003 10:54 AM
> To: Brian Rosen; Dean Willis; [email-masked]
> Cc: [email-masked]
> Dial strings have usually been defined to include things like 
> pauses and
> wait for secondary dial tone. I don't think we need to be 
> able to represent
> that type of information in SIP.
> 
> Cullen
> 
> 
> On 8/28/03 11:15, "Rosen, Brian" <[email-masked]> wrote:
>

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 29 Aug 2003 18:01:27 -0500

> > The same way it routes sip:[email-masked]
> 
> Tell that to Dean :) He thinks it is not routable (that's the
> point I was trying to make).

Ah, I see our disconnect. you're talking phone-context as defined in
2806bis. That's "broken", for some definition of the word, and I was
phone-context as defined in 2806.

The syntax of 2806 looked more like:

phone-context-tag     = "phone-context"
phone-context-ident   = network-prefix / private-prefix
network-prefix        = global-network-prefix / local-network-prefix
global-network-prefix = "+" 1*phonedigit
local-network-prefix  = 1*(phonedigit / dtmf-digit / pause-character)
private-prefix        = (%x21-22 / %x24-27 / %x2C / %x2F / %x3A /
                        %x3C-40 / %x45-4F / %x51-56 / %x58-60 /
                        %x65-6F / %x71-76 / %x78-7E)
                        *(%x21-3A / %x3C-7E)
                        ; Characters in URLs must follow escaping rules
                        ; as explained in [RFC2396]

This lets one encode nearly anything into the phone-context and has no
presumtion of global meaningfulness, at least in the private-prefix
production.

If I remember correctly, it was at my urging that Antti added phone-context
originally.

The reason I pushed it was because, at the time, we (of that time, MCI) were
using it to encode trunk-group IDs and switch port numbers and all sorts of
other "non global" stuff.  As far as I know, it still works that way there.
The bis changes are dramatically not compatible. I've been hoping Alan
Johnston would raise the point, if it still applies. Maybe it doesn't matter
any more.

--
Dean

---

From: "Hearty, John" <[email-masked]>
Date: Fri, 29 Aug 2003 08:37:26 -0600

If it helps build consensus any, I suspect there are more folks like
myself that have not spoken up yet because we don't interpret
user=phone, and thus don't care if it gets depreciated.

John Hearty
Level3

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
> Roach
> Sent: Thursday, August 28, 2003 3:30 PM
> To: 'Rosen, Brian'; 'Stastny Richard'; Rohan Mahy
> Cc: Adam Roach; [email-masked]