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

From: [email-masked]
Date: Mon, 1 Sep 2003 11:45:29 +0300

So, I'll ask the question again, this time for real:

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? Or how does it discover the proxy at munich.example.com?

The reason I'm asking this again is due to my proposal in earlier emails to use a tel URI for dial strings and sip URI for pure sip users.

Is there something wrong with mandating that if an entity placed a tel-URI in a sip request along with a phone-context carrying a domain name, then that domain name must be the address of a sip proxy? 

/Hisham

> -----Original Message-----
> From: ext Cullen Jennings [mailto:[email-masked]]
> Sent: Saturday, August 30, 2003 2:48 AM
> To: Stastny Richard; Khartabil Hisham (NMP/Helsinki); Dean Willis
> Cc: Brian Rosen; [email-masked]
> Subject: Re: AW: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> I don't know what I was thinking - I gave the wrong answer. 
> The context in
> the tel does not at mean you should attempt to route the call 
> to there - it
> is just an identifier of the namespace of who understands the number.
> 
> On 8/29/03 13:50, "Stastny Richard" <[email-masked]> wrote:
> 
> >>> So, how does the proxy route this message to munich.example.com?
> >>> 
> >>> /Hisham
> >>> 
> >> 
> >> 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).
> > 
> > Warning: this needs NOT to be true and IMHO this part of
> > the informational section is misleading. In section 5.1.4 
> Local numbers
> > it is clearly stated:
> > 
> > "There are two ways to label the context: via a global 
> number or any    |
> >  number of its leading digits (e.g., "+33") and via a 
> domain name,      |
> >  e.g., "houston.example.com". The choice between the two is 
> left to     |
> >  the "owner" of the local number and is governed by whether 
> there is a  |
> >  global number or domain name that is a valid identifier 
> for a          |
> >  particular local number.
> >                                             |
> >  The domain name does not have to resolve to any actual 
> host, but MUST  |
> >  be under the administrative control of the entity managing 
> the local   |
> >  phone context. "
> > 
> > Since the domain name does not have to resolve to an actual host,
> > one cannot rely on this, so your statement may be wrong.
> > 
> > Richard
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: [email-masked] [mailto:[email-masked]]
> > Gesendet: Fr 29.08.2003 17:31
> > An: [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Betreff: RE: AW: [Sip] SIPIT Interop problem with ;user=phone
> > 
> > 
> > 
> > 
> > 
> >> -----Original Message-----
> >> From: ext Cullen Jennings [mailto:[email-masked]]
> >> Sent: Friday, August 29, 2003 5:51 PM
> >> To: Khartabil Hisham (NMP/Helsinki); Dean Willis
> >> Cc: Brian Rosen; [email-masked]
> >> Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone
> >> 
> >> 
> >> On 8/29/03 1:03, "[email-masked]"
> >> <[email-masked]>
> >> wrote:
> >> 
> >>> 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?
> >>> 
> >>> /Hisham
> >>> 
> >> 
> >> 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).
> > 
> > Regards,
> > Hisham
> > 
> > 
> >> 
> >> 
> >> 
> > 
> > _______________________________________________
> > 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
> > 
> > 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: [email-masked]
Date: Mon, 1 Sep 2003 12:21:22 +0300

So, the answer in any case is that it is somehow routable. Therefore I conclude the allowing a sip URI to carry a dial strings is not needed.

/Hisham

> From: ext Stastny Richard [mailto:[email-masked]]
> Sent: Monday, September 01, 2003 12:20 PM
> To: Khartabil Hisham (NMP/Helsinki); [email-masked];
> [email-masked]
> Subject: AW: AW: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> You should not need to route this call anyway, because 
> normally you should
> not see such a context out of the context. The idea is: if 
> you know the context
> then you also know how to route the call, if you do not know 
> the context,
> you just say invalid number. In other contexts only global 
> understandable
> URIs should be used
>  
> Richard
> 
> 	Gesendet: Mo 01.09.2003 10:45 
> 	An: [email-masked]; Stastny Richard; 
> [email-masked] 
> 	Betreff: RE: AW: AW: [Sip] SIPIT Interop problem with 
> ;user=phone
> 	
> 	
> 
> "tel" URIs with SIP (Informative)", it says:
> 	
> 	"
> 	So, how does the proxy route this message to 
> munich.example.com? Or how does it discover the proxy at 
> munich.example.com?
> 	
> 	The reason I'm asking this again is due to my proposal 
> in earlier emails to use a tel URI for dial strings and sip 
> URI for pure sip users.
> 	
> 	Is there something wrong with mandating that if an 
> entity placed a tel-URI in a sip request along with a 
> phone-context carrying a domain name, then that domain name 
> must be the address of a sip proxy?
> 	
> 	/Hisham
> 	
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: "Stastny Richard" <[email-masked]>
Date: Mon, 1 Sep 2003 11:19:56 +0200

WW91IHNob3VsZCBub3QgbmVlZCB0byByb3V0ZSB0aGlzIGNhbGwgYW55d2F5LCBiZWNhdXNlIG5vcm1hbGx5IHlvdSBzaG91bGQNCm5vdCBzZWUgc3VjaCBhIGNvbnRleHQgb3V0IG9mIHRoZSBjb250ZXh0LiBUaGUgaWRlYSBpczogaWYgeW91IGtub3cgdGhlIGNvbnRleHQNCnRoZW4geW91IGFsc28ga25vdyBob3cgdG8gcm91dGUgdGhlIGNhbGwsIGlmIHlvdSBkbyBub3Qga25vdyB0aGUgY29udGV4dCwNCnlvdSBqdXN0IHNheSBpbnZhbGlkIG51bWJlci4gSW4gb3RoZXIgY29udGV4dHMgb25seSBnbG9iYWwgdW5kZXJzdGFuZGFibGUNClVSSXMgc2hvdWxkIGJlIHVzZWQNCiANClJpY2hhcmQNCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBoaXNoYW0ua2hhcnRhYmlsQG5va2lhLmNvbSBbbWFpbHRvOmhpc2hhbS5raGFydGFiaWxAbm9raWEuY29tXSANCglHZXNlbmRldDogTW8gMDEuMDkuMjAwMyAxMDo0NSANCglBbjogZmx1ZmZ5QGNpc2NvLmNvbTsgU3Rhc3RueSBSaWNoYXJkOyBkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tIA0KCUNjOiBCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbTsgc2lwQGlldGYub3JnIA0KCUJldHJlZmY6IFJFOiBBVzogQVc6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lDQoJDQoJDQoNCglTbywgSSdsbCBhc2sgdGhlIHF1ZXN0aW9uIGFnYWluLCB0aGlzIHRpbWUgZm9yIHJlYWw6DQoJDQoJVW5kZXIgdGhlIGluZm9ybWF0aXZlIHRleHQgaW4gMjgwNmJpcyBsYWJlbGVkICJBIFVzZSBvZiAidGVsIiBVUklzIHdpdGggU0lQIChJbmZvcm1hdGl2ZSkiLCBpdCBzYXlzOg0KCQ0KCSINCgkgICAgICAgICAgICAgMi4gICBUaGUgb3V0Ym91bmQgcHJveHkgZG9lcyBub3QgdXNlIHRoZSBzYW1lIHBob25lDQoJICAgICAgICAgICAgICAgICAgY29udGV4dCwgYnV0IGNhbiByb3V0ZSB0byBhIHByb3h5IHRoYXQgaGFuZGxlcyB0aGlzDQoJICAgICAgICAgICAgICAgICAgcGhvbmUgY29udGV4dC4gVGhpcyByb3V0aW5nIGNhbiBiZSBkb25lIHZpYSBhIGxvb2t1cA0KCSAgICAgICAgICAgICAgICAgIHRhYmxlIG9yIHRoZSBkb21haW4gbmFtZSBvZiB0aGUgcGhvbmUgY29udGV4dCBtaWdodCBiZQ0KCSAgICAgICAgICAgICAgICAgIHNldCB1cCB0byByZWZsZWN0IHRoZSBTSVAgZG9tYWluIG5hbWUgb2YgYSBzdWl0YWJsZQ0KCSAgICAgICAgICAgICAgICAgIHByb3h5LiBGb3IgZXhhbXBsZSwgYSBwcm94eSBtYXkgYWx3YXlzIHJvdXRlIGNhbGxzDQoJICAgICAgICAgICAgICAgICAgd2l0aCB0ZWwgVVJJcyBsaWtlDQoJDQoJICAgICAgICAgICAgICAgICAgdGVsOjEyMzQ7cGhvbmUtY29udGV4dD1tdW5pY2guZXhhbXBsZS5jb20NCgkNCgkgICAgICAgICAgICAgICAgICB0byB0aGUgU0lQIHByb3h5IGxvY2F0ZWQgYXQgbXVuaWNoLmV4YW1wbGUuY29tLiINCgkNCgkNCglTbywgaG93IGRvZXMgdGhlIHByb3h5IHJvdXRlIHRoaXMgbWVzc2FnZSB0byBtdW5pY2guZXhhbXBsZS5jb20/IE9yIGhvdyBkb2VzIGl0IGRpc2NvdmVyIHRoZSBwcm94eSBhdCBtdW5pY2guZXhhbXBsZS5jb20/DQoJDQoJVGhlIHJlYXNvbiBJJ20gYXNraW5nIHRoaXMgYWdhaW4gaXMgZHVlIHRvIG15IHByb3Bvc2FsIGluIGVhcmxpZXIgZW1haWxzIHRvIHVzZSBhIHRlbCBVUkkgZm9yIGRpYWwgc3RyaW5ncyBhbmQgc2lwIFVSSSBmb3IgcHVyZSBzaXAgdXNlcnMuDQoJDQoJSXMgdGhlcmUgc29tZXRoaW5nIHdyb25nIHdpdGggbWFuZGF0aW5nIHRoYXQgaWYgYW4gZW50aXR5IHBsYWNlZCBhIHRlbC1VUkkgaW4gYSBzaXAgcmVxdWVzdCBhbG9uZyB3aXRoIGEgcGhvbmUtY29udGV4dCBjYXJyeWluZyBhIGRvbWFpbiBuYW1lLCB0aGVuIHRoYXQgZG9tYWluIG5hbWUgbXVzdCBiZSB0aGUgYWRkcmVzcyBvZiBhIHNpcCBwcm94eT8NCgkNCgkvSGlzaGFtDQoJDQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4gRnJvbTogZXh0IEN1bGxlbiBKZW5uaW5ncyBbbWFpbHRvOmZsdWZmeUBjaXNjby5jb21dDQoJPiBTZW50OiBTYXR1cmRheSwgQXVndXN0IDMwLCAyMDAzIDI6NDggQU0NCgk+IFRvOiBTdGFzdG55IFJpY2hhcmQ7IEtoYXJ0YWJpbCBIaXNoYW0gKE5NUC9IZWxzaW5raSk7IERlYW4gV2lsbGlzDQoJPiBDYzogQnJpYW4gUm9zZW47IHNpcEBpZXRmLm9yZw0KCT4gU3ViamVjdDogUmU6IEFXOiBBVzogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggO3VzZXI9cGhvbmUNCgk+DQoJPg0KCT4NCgk+IEkgZG9uJ3Qga25vdyB3aGF0IEkgd2FzIHRoaW5raW5nIC0gSSBnYXZlIHRoZSB3cm9uZyBhbnN3ZXIuDQoJPiBUaGUgY29udGV4dCBpbg0KCT4gdGhlIHRlbCBkb2VzIG5vdCBhdCBtZWFuIHlvdSBzaG91bGQgYXR0ZW1wdCB0byByb3V0ZSB0aGUgY2FsbA0KCT4gdG8gdGhlcmUgLSBpdA0KCT4gaXMganVzdCBhbiBpZGVudGlmaWVyIG9mIHRoZSBuYW1lc3BhY2Ugb2Ygd2hvIHVuZGVyc3RhbmRzIHRoZSBudW1iZXIuDQoJPg0KCT4gT24gOC8yOS8wMyAxMzo1MCwgIlN0YXN0bnkgUmljaGFyZCIgPFJpY2hhcmQuU3Rhc3RueUBvZWZlZy5hdD4gd3JvdGU6DQoJPg0KCT4gPj4+IFNvLCBob3cgZG9lcyB0aGUgcHJveHkgcm91dGUgdGhpcyBtZXNzYWdlIHRvIG11bmljaC5leGFtcGxlLmNvbT8NCgk+ID4+Pg0KCT4gPj4+IC9IaXNoYW0NCgk+ID4+Pg0KCT4gPj4NCgk+ID4+IFRoZSBzYW1lIHdheSBpdCByb3V0ZXMgc2lwOmZsdWZmeUBtdW5pY2guZXhhbXBsZS5jb20NCgk+ID4NCgk+ID4gVGVsbCB0aGF0IHRvIERlYW4gOikgSGUgdGhpbmtzIGl0IGlzIG5vdCByb3V0YWJsZSAodGhhdCdzDQoJPiB0aGUgcG9pbnQgSSB3YXMNCgk+ID4gdHJ5aW5nIHRvIG1ha2UpLg0KCT4gPg0KCT4gPiBXYXJuaW5nOiB0aGlzIG5lZWRzIE5PVCB0byBiZSB0cnVlIGFuZCBJTUhPIHRoaXMgcGFydCBvZg0KCT4gPiB0aGUgaW5mb3JtYXRpb25hbCBzZWN0aW9uIGlzIG1pc2xlYWRpbmcuIEluIHNlY3Rpb24gNS4xLjQNCgk+IExvY2FsIG51bWJlcnMNCgk+ID4gaXQgaXMgY2xlYXJseSBzdGF0ZWQ6DQoJPiA+DQoJPiA+ICJUaGVyZSBhcmUgdHdvIHdheXMgdG8gbGFiZWwgdGhlIGNvbnRleHQ6IHZpYSBhIGdsb2JhbA0KCT4gbnVtYmVyIG9yIGFueSAgICB8DQoJPiA+ICBudW1iZXIgb2YgaXRzIGxlYWRpbmcgZGlnaXRzIChlLmcuLCAiKzMzIikgYW5kIHZpYSBhDQoJPiBkb21haW4gbmFtZSwgICAgICB8DQoJPiA+ICBlLmcuLCAiaG91c3Rvbi5leGFtcGxlLmNvbSIuIFRoZSBjaG9pY2UgYmV0d2VlbiB0aGUgdHdvIGlzDQoJPiBsZWZ0IHRvICAgICB8DQoJPiA+ICB0aGUgIm93bmVyIiBvZiB0aGUgbG9jYWwgbnVtYmVyIGFuZCBpcyBnb3Zlcm5lZCBieSB3aGV0aGVyDQoJPiB0aGVyZSBpcyBhICB8DQoJPiA+ICBnbG9iYWwgbnVtYmVyIG9yIGRvbWFpbiBuYW1lIHRoYXQgaXMgYSB2YWxpZCBpZGVudGlmaWVyDQoJPiBmb3IgYSAgICAgICAgICB8DQoJPiA+ICBwYXJ0aWN1bGFyIGxvY2FsIG51bWJlci4NCgk+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoJPiA+ICBUaGUgZG9tYWluIG5hbWUgZG9lcyBub3QgaGF2ZSB0byByZXNvbHZlIHRvIGFueSBhY3R1YWwNCgk+IGhvc3QsIGJ1dCBNVVNUICB8DQoJPiA+ICBiZSB1bmRlciB0aGUgYWRtaW5pc3RyYXRpdmUgY29udHJvbCBvZiB0aGUgZW50aXR5IG1hbmFnaW5nDQoJPiB0aGUgbG9jYWwgICB8DQoJPiA+ICBwaG9uZSBjb250ZXh0LiAiDQoJPiA+DQoJPiA+IFNpbmNlIHRoZSBkb21haW4gbmFtZSBkb2VzIG5vdCBoYXZlIHRvIHJlc29sdmUgdG8gYW4gYWN0dWFsIGhvc3QsDQoJPiA+IG9uZSBjYW5ub3QgcmVseSBvbiB0aGlzLCBzbyB5b3VyIHN0YXRlbWVudCBtYXkgYmUgd3JvbmcuDQoJPiA+DQoJPiA+IFJpY2hhcmQNCgk+ID4NCgk+ID4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KCT4gPiBWb246IGhpc2hhbS5raGFydGFiaWxAbm9raWEuY29tIFttYWlsdG86aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb21dDQoJPiA+IEdlc2VuZGV0OiBGciAyOS4wOC4yMDAzIDE3OjMxDQoJPiA+IEFuOiBmbHVmZnlAY2lzY28uY29tOyBkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tDQoJPiA+IENjOiBCcmlhbi5Sb3NlbkBtYXJjb25pLmNvbTsgc2lwQGlldGYub3JnDQoJPiA+IEJldHJlZmY6IFJFOiBBVzogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggO3VzZXI9cGhvbmUNCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiA+PiBGcm9tOiBleHQgQ3VsbGVuIEplbm5pbmdzIFttYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbV0NCgk+ID4+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDI5LCAyMDAzIDU6NTEgUE0NCgk+ID4+IFRvOiBLaGFydGFiaWwgSGlzaGFtIChOTVAvSGVsc2lua2kpOyBEZWFuIFdpbGxpcw0KCT4gPj4gQ2M6IEJyaWFuIFJvc2VuOyBzaXBAaWV0Zi5vcmcNCgk+ID4+IFN1YmplY3Q6IFJlOiBBVzogW1NpcF0gU0lQSVQgSW50ZXJvcCBwcm9ibGVtIHdpdGggO3VzZXI9cGhvbmUNCgk+ID4+DQoJPiA+Pg0KCT4gPj4gT24gOC8yOS8wMyAxOjAzLCAiaGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb20iDQoJPiA+PiA8aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb20+DQoJPiA+PiB3cm90ZToNCgk+ID4+DQoJPiA+Pj4gVW5kZXIgdGhlIGluZm9ybWF0aXZlIHRleHQgaW4gMjgwNmJpcyBsYWJlbGVkICJBIFVzZSBvZg0KCT4gPj4gInRlbCIgVVJJcyB3aXRoIFNJUA0KCT4gPj4+IChJbmZvcm1hdGl2ZSkiLCBpdCBzYXlzOg0KCT4gPj4+DQoJPiA+Pj4gIg0KCT4gPj4+ICAgICAgICAgICAgMi4gICBUaGUgb3V0Ym91bmQgcHJveHkgZG9lcyBub3QgdXNlIHRoZSBzYW1lIHBob25lDQoJPiA+Pj4gICAgICAgICAgICAgICAgIGNvbnRleHQsIGJ1dCBjYW4gcm91dGUgdG8gYSBwcm94eSB0aGF0DQoJPiBoYW5kbGVzIHRoaXMNCgk+ID4+PiAgICAgICAgICAgICAgICAgcGhvbmUgY29udGV4dC4gVGhpcyByb3V0aW5nIGNhbiBiZSBkb25lDQoJPiB2aWEgYSBsb29rdXANCgk+ID4+PiAgICAgICAgICAgICAgICAgdGFibGUgb3IgdGhlIGRvbWFpbiBuYW1lIG9mIHRoZSBwaG9uZQ0KCT4gPj4gY29udGV4dCBtaWdodCBiZQ0KCT4gPj4+ICAgICAgICAgICAgICAgICBzZXQgdXAgdG8gcmVmbGVjdCB0aGUgU0lQIGRvbWFpbiBuYW1lIG9mDQoJPiBhIHN1aXRhYmxlDQoJPiA+Pj4gICAgICAgICAgICAgICAgIHByb3h5LiBGb3IgZXhhbXBsZSwgYSBwcm94eSBtYXkgYWx3YXlzIHJvdXRlIGNhbGxzDQoJPiA+Pj4gICAgICAgICAgICAgICAgIHdpdGggdGVsIFVSSXMgbGlrZQ0KCT4gPj4+DQoJPiA+Pj4gICAgICAgICAgICAgICAgIHRlbDoxMjM0O3Bob25lLWNvbnRleHQ9bXVuaWNoLmV4YW1wbGUuY29tDQoJPiA+Pj4NCgk+ID4+PiAgICAgICAgICAgICAgICAgdG8gdGhlIFNJUCBwcm94eSBsb2NhdGVkIGF0IG11bmljaC5leGFtcGxlLmNvbS4iDQoJPiA+Pj4NCgk+ID4+Pg0KCT4gPj4+IFNvLCBob3cgZG9lcyB0aGUgcHJveHkgcm91dGUgdGhpcyBtZXNzYWdlIHRvIG11bmljaC5leGFtcGxlLmNvbT8NCgk+ID4+Pg0KCT4gPj4+IC9IaXNoYW0NCgk+ID4+Pg0KCT4gPj4NCgk+ID4+IFRoZSBzYW1lIHdheSBpdCByb3V0ZXMgc2lwOmZsdWZmeUBtdW5pY2guZXhhbXBsZS5jb20NCgk+ID4NCgk+ID4gVGVsbCB0aGF0IHRvIERlYW4gOikgSGUgdGhpbmtzIGl0IGlzIG5vdCByb3V0YWJsZSAodGhhdCdzDQoJPiB0aGUgcG9pbnQgSSB3YXMNCgk+ID4gdHJ5aW5nIHRvIG1ha2UpLg0KCT4gPg0KCT4gPiBSZWdhcmRzLA0KCT4gPiBIaXNoYW0NCgk+ID4NCgk+ID4NCgk+ID4+DQoJPiA+Pg0KCT4gPj4NCgk+ID4NCgk+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+ID4gU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQoJPiA+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KCT4gPiBVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcA0KCT4gPiBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQoJPiA+DQoJPiA+DQoJPg0KCT4NCgk+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJPiBTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXANCgk+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KCT4gVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXANCgk+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCgk+DQoJDQoNCg==_______________________________________________Sip mailing list  https://www1.ietf.org/mailman/listinfo/sipThis list is for NEW development of the core SIP ProtocolUse [email-masked] for questions on current sipUse [email-masked] for new developments on the application of sip

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 2 Sep 2003 13:34:08 -0400

Many phones do this.

Some phones have the local dial plan interpreted in the phone,
and only emit "complete" (within the domain) phone numbers.
Some will send a tel uri, some will send the number in a sip
uri in the local (configured) domain.

I think that for most dial plans you can safely translate such
a number again by the proxy, but I worry that that is not ALWAYS
true.  So, I think it might be useful to mark a sip uri with
an uninterpreted dial string differently from a sip uri with
an interpreted phone number.  I also wonder if it might be
helpful in other circumstances; for example, where there are
several proxies in the path which have the capability to
translate dial strings to phone numbers.  Generally, I think
it's always the case that the first proxy encountered that
has the capability should do the translation.  I think it might
be useful for a succeeding proxy to know that it should NOT
translate (because it has already been translated).

Brian

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Tuesday, September 02, 2003 12:55 PM
> To: Rosen, Brian
> Cc: [email-masked]'; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: AW: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> Rosen, Brian writes:
> 
>  > I think your example not ideal only because a UA could
>  > have a trivial rule that a number starting with + is known to
>  > be a globally dialable number, and thus COULD be put in a tel
>  > uri.  
> 
> 
> no matter what number the user dials (with or without +), my sip phone
> will do the same thing:  append its own domain to the number 
> and forward
> the call to the proxy of the domain.  the proxy of the phone's domain
> will then interpret the number according to the conventions that exist
> within the domain.
> 
> -- juha
>

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 3 Sep 2003 12:38:52 +0200

Juha wrote:

> 
> it is thus the responsibility of the user to figure out, how 
> to turn 0401234567 into something that is correctly routable 
> by the proxy of that user the user might, for example, try to 
> figure out from the address on the business card in which 
> country the person lives and then add the corresponding cc 
> into the number.  
> 
> that is what people do every day when they have to deal with 
> local phone numbers in other regions.  i don't understand why 
> we discuss this on a mailing list of a standards body.
> 
> -- juha
> 

Amen,
Richard

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Sep 2003 08:40:46 -0400

I think you have been given the wrong answer.
   Phone: 0401234567
if dialed, you would enter the digits 0-4-1-2-3-4-5-6-7,
and the uac, if it did not know how to translate dial strings
to telephone numbers would send
  0401234567@localdomain; user=phone

  SIP: [email-masked]
if dialed, would result in the uac sending
  [email-masked]

The original reason for user=phone was to differentiate
between these two cases, where localdomain=tutpro.com,
and it was intended that the resulting uas was different. 

I would say that the former results in a dial string, and
the latter does not.  I think it is very useful for the
proxy to be able to know that the user part of the uri is
a dial string and not a phone number and not a username.

I think a phone number should be sent in a tel uri, at least
on a go forward basis, and not in a sip uri.  If some proxy
has turned a phone number into a sip uri (by an enum dip for
example), then the result will be a sip uri which is NOT
a phone number, nor a dial string.  This may or may not have
numeric username.  A downstream proxy should be able to
differentiate all of these cases, so that, for example,
it does not invoke dial string to phone number processing,
or another enum dip.  

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 03, 2003 6:58 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked];
> We both live in Finland. You expect me to dial +358 every 
> time I call you?
> 
> > From: ext Juha Heinanen [mailto:[email-masked]]
> > Sent: Wednesday, September 03, 2003 1:31 PM
> > To: Khartabil Hisham (NMP/Helsinki)
> > Cc: [email-masked]; [email-masked]; 
> > [email-masked];
> > [email-masked] writes:
> > 
> >  > When if I hand you this on a business card:
> >  > 
> >  > Phone: 0401234567
> >  > 
> >  > and one of your colleagues hands you this:
> >  > 
> >  > SIP: [email-masked]
> >  > 
> >  > What do you dial to call me and what do you dial to call your
> >  > colleague, using your phone? How does your proxy tell the 
> > difference?
> > 
> > what would the phone network do if someone in india dials the 
> > number you
> > gave?  it would do the same as my proxy:  route the call to a
> > destination in a wrong local network or declare the destination
> > unreachable.
> > 
> > it is thus the responsibility of the user to figure out, how to turn
> > 0401234567 into something that is correctly routable by the proxy of
> > that user the user might, for example, try to figure out from the
> > address on the business card in which country the person 
> > lives and then
> > add the corresponding cc into the number.  
> > 
> > local phone
> > numbers in other regions.  i don't understand why we 
> discuss this on a
> > mailing list of a standards body.
> > 
> > -- juha
> > 
>

---

From: [email-masked]
Date: Wed, 3 Sep 2003 15:54:04 +0300

I agree with everything that Brian just posted.

There is one small issue left: Should we require the user to always input the domain name in a sip address (the @tutpro.com even if its a local call). I'm too lazy to type it into my phone if I'm calling a someone in the same domain (this is a handset configuration issue).

If the handset enables you to just type the username part of a sip address for local calls, then you have to tell it if you intension was to dial

0401234567

or

0401234567

So it know to put user=phone or not.

/Hisham

> From: ext Rosen, Brian [mailto:[email-masked]]
> Sent: Wednesday, September 03, 2003 3:41 PM
> To: Khartabil Hisham (NMP/Helsinki); [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 3 Sep 2003 18:21:09 -0700

> > I've never understood that user=phone was intended for tel 
> to sip uri 
> > conversion.
> 
> Well, maybe not. But clearly a lot of people do, including 
> me. Section 
> 19.1.6 of 3261 is pretty clear:
> 
>     When a tel URL (RFC 2806 [9]) is converted to a SIP or 
> SIPS URI, the
>     entire telephone-subscriber portion of the tel URL, including any
>     parameters, is placed into the userinfo part of the SIP 
> or SIPS URI.

This is fairly important. It is also stated in the BNF in note on page 223
that the telephone-subscriber definition is as per RFC2806.

What is not explicitely said, but probably should, is that having
a URI with a user-info composed with a telephone-subscriber (as opposed
to a user), as per the BNF definition, it means that the user=phone
user-param needs to be included. This is somewhat implicit in the examples
in 19.1.6, but it should probably be more explicit. And we should probably
clarify that you user=phone shouldn't be used for other purposes, such as
saying that the end-device looks like a phone. 

I've asked the same question a few months ago on this list and the answer
I got (from Jonathan Rosenberg if my memory serves me right) was that indeed
having
user=phone user-param included in the SIP-URI meant that the userinfo
included a 
telephone-subscriber and not a user.

I think we should stick to this, and make it explicit in RFC3261. This would
clarify that user=phone means that 2806 format is used in the SIP-URI, and
not
that the user is talking into a "physical" phone.

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 4 Sep 2003 13:12:58 +0200

I do not really understand this discussion, because IMHO
not even ;user=phone is necessary, not to talk about any additional
parameters.

As Christer said, sip:[email-masked] or tel:+xxx shall work in any case
(if E.164 numbers are supported).

For local numbers and dialstrings the system currently implemented
between FWD et. al. perfectly works (without ;user=phone)
It is using only sip: URIs in the following way:

If you use an UAC where you may enter a complete sip: URI
the INVITE is forwarded to the proper domain as is.

If you use a "phone" and enter a numeric string forwarded to
the default proxy foo.bar in the format [email-masked]

It is now up to this proxy to analyze the ddddd. If it does not
support numbers or dialstrings at all, he may reject it anyway.

If it support numbers, it first checks if the number is used as an alias
for a user (e.g. 10000 for jeff)

If this is not the case, it may be a dialstring e.g. (**7476691290 for a
sipphone user)

E.g sipphone is not using **, they use dummy areacodes:
you dial 17476691290 for own users (=alias), but 139310000 for FWD
and 14788781 for an iptel.org user

FWD is even allowing transit calls:
so from sipphone you may access an iptel.org user
either with entering [email-masked] in messenger or
dial 1393**4788781 on the grandstream phone

What is happening here is classical digit translation:
the phone is sending sip:[email-masked]
siphone is sending sip:[email-masked]
FWD is sending [email-masked]

Personal note: I do not think that this approach is feasable for
the interconnection of may different proxies, but it works.Finally we 
should end up using only FQDN E.164 numbers or sip AoRs.

To summarise: either you use a global number with + or a local dialing
(numbering) plan
You normally can use only one local dialing plan as default (same as in
the PSTN).

You may access another dialing plan directly by sending a sip URI
directly
to the domain in question (as in the above examples sending
[email-masked] directly)
but this does not make much sense on a phone, because if you do this,
you do not need 
a dialing plan anyway, you could also enter a sip AoR .

regards
Richard

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: Thursday, September 04, 2003 12:14 PM
> To: 'Bob Penfield'; [email-masked]
> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> Hi,
> 
> I would support Bob's proposal, saying that a "+" indicates 
> global-phone-number, according to RFC2806(or bis). I don't 
> think there would be any backward compability issues, because 
> I doubt anyone is using "+" for any other purpose - at least 
> not as the first character of the user part. Of course, nodes 
> that really REQUIRE user=phone to be present, in order to 
> accept the request in the first, place would have to be changed.
> 
> Of course, user=tel could also be used, but I really see no 
> use for that if the "+" rule applies. Also, user=tel COULD 
> cause backward compability issues.
> 
> Then, since there doesn't seem to be an agreement on what 
> user=phone really means, related BOTH to the userpart syntax 
> and the message routing, we could remove it completely.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> 
> > From: Bob Penfield [mailto:[email-masked]]
> > Sent: 4. syyskuuta 2003 2:43
> > To: [email-masked]
> > Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
> > 
> > 
> > Getting back to the problem Robert described in the 
> original mail, the 
> > interoperability problems are a result of that fact that what is a 
> > valid userinfo part of a SIP URL with a user=phone parameter has
> > steadily gotten
> > stricter without any consideration for backwards 
> > compatibility. The specific
> > problem he described resulted because a SIP URL created with 
> > 2543 rules was
> > rejected by a server applying 3261/2806 rules. The new 
> > 2806bis rules are
> > even stricter. I have no problem with those rules for tel-URLs.
> > 
> > In spite of the lack of normative text on user-phone, the
> > statements in 2543
> > and 3261 to the effect that it is used to distinguish phone 
> > numbers from
> > usernames leads one to the reasonable conclusion that when it 
> > is present,
> > the 'telephone-subscriber' BNF applies. This is the 
> > conclusion that we and a
> > number of our vendors and customers came to when we ran into interop
> > problems.
> > 
> > However, its not that simple since a 'telephone-subscriber'
> > keeps changing.
> > 
> > >From some of the posting on this subject, there seems to 
> be value in
> > distinguishing a telephone number from username that happens
> > to look like a
> > telephone number without requiring that the user part be a 
> > tel-URL. What I
> > would propose is that while we make the rules for user=phone 
> > clearer, they
> > ought to be closer to the 2543 rules which in my experience a lot of
> > existing implementation seem to follow. If the userinfo 
> > begins with "+" or
> > contains a phone-context, then it is reasonable to interpret it as a
> > tel-URL. Otherwise, the 'local-phone-number' (from Table 4 of 
> > 2543) should
> > apply. A server which is not responsible for the domain of 
> the SIP URL
> > should not reject a SIP URL because phone-context is missing. 
> > Actually, I
> > believe it is reasonable to take the SIP URL host part as the 
> > 'default'
> > phone-context when it is missing.
> > 
> > Also, we could add 'user=tel' for userinfo that MUST be
> > tel-URLs. In that
> > case, rejecting a local number without a phone-context would 
> > be perfectly
> > reasonable.
> > 
> > cheers,
> > (-:bob
> > 
> > Robert F. Penfield
> > Chief Software Architect
> > Acme Packet, Inc.
> > 130 New Boston Street
> > Woburn, MA 01801
> > [email-masked]
> > 
> > 
> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 4 Sep 2003 14:14:51 +0200

> What if the domain is the sip URI is the same domain as where 
> the default proxy is.
> 
> So, if I enter sip:[email-masked] or just enter the digits 
> 12345, they will both be placed in the INVITE as 
> sip:[email-masked]. How is the proxy foo.bar supposed to know 
> the difference? Especially is user with phone 12345 is 
> different that user with URI sip:[email-masked]

The simplest solution to this problem is very trivial: there is no
difference:

sip:[email-masked] is sip:[email-masked] (surprise, surprise)

The is BTW exactly how it is implemented in the examples I gave.
[email-masked] is e.g. an alias of [email-masked]

The only restriction you have to keep in mind here is that 12345 is also
a number from a numbering plan. If you now also implement a dialing plan
you
have to leave number ranges free in your aliases for access codes 
(e.g. start no alias with 0 to allow dialing 00 or 011 or whatever.)

BTW, we use this also to map this "numbers" as partial numbers to E.164
numbers:

My SIP AoR is e.g. [email-masked], the alias is [email-masked], so
within
my context I can be "dialed" also with 32. The E.164 number mapped with 
ENUM is +4317978032, which translates to sip:[email-masked]
(You may look up the NAPTR in 2.3.0.8.7.9.7.1.3.4.e164.arpa)

regards
Richard

> Sent: Thursday, September 04, 2003 1:52 PM
> To: Stastny Richard; [email-masked]; 
> [email-masked]; [email-masked]
> > Sent: Thursday, September 04, 2003 2:13 PM
> > To: Christer Holmberg (JO/LMF); Bob Penfield; [email-masked]
> > If you use a "phone" and enter a numeric string forwarded to the 
> > default proxy foo.bar in the format [email-masked]
> > 
> What if the domain is the sip URI is the same domain as where 
> the default proxy is.
> 
> So, if I enter sip:[email-masked] or just enter the digits 
> 12345, they will both be placed in the INVITE as 
> sip:[email-masked]. How is the proxy foo.bar supposed to know 
> the difference? Especially is user with phone 12345 is 
> different that user with URI sip:[email-masked]
> 
> There are 2 solutions in my mind (I can't see how this can be 
> solved without user input):
> 
> 1. Mandate that endpoints support tel URIs. If user inputs 
> digits, the they are placed in a tel URI. In this case, the 
> endpoint must not accept a invalid tel URI entry without a 
> phone-context. For local calls, the endpoint prepends the 
> +CountryCode-AreaCode it is configured with (if the user is 
> not required to enter them).
> 
> 2. Mandate that users select what type of URI s/he is typing 
> in (a sip or tel URI). Based on that, place user=phone. 
> 
> Note, this is different than that Brain is talking about 
> where the proxy translates a tel URI in to a sip URI using 
> ENUM. There he wants the proxy to place something like 
> user=translated-from-tel.
> 
> Regards,
> Hisham
> 
> > 
> > you dial 17476691290 for own users (=alias), but 139310000 
> for FWD and 
> > 14788781 for an iptel.org user
> > 
> > Personal note: I do not think that this approach is 
> feasable for the 
> > interconnection of may different proxies, but it works.Finally we 
> > directly to the domain in question (as in the above examples sending
> > [email-masked] directly)
> > > > steadily gotten stricter without any consideration for backwards
> > > > statements in 2543 and 3261 to the effect that it is used to 
> > > > distinguish phone numbers from
> > > > However, its not that simple since a 
> 'telephone-subscriber' keeps 
> > > > changing.
> > > > 
> > > > distinguishing a telephone number from username that happens to 
> > > > look like a telephone number without requiring that the 
> user part 
> > > > be a tel-URL. What I
> tel-URLs. 
> > > > In that case, rejecting a local number without a phone-context 
> > > > would be perfectly
> > > > reasonable.
> > > > 
> > > > cheers,
> > > > (-:bob
> > > > 
> > > > Robert F. Penfield
> > > > Chief Software Architect
> > > > Acme Packet, Inc.
> > > > 130 New Boston Street
> > > > Woburn, MA 01801
> > > > [email-masked]
> > > > 
> > > > 
> > > > This list is for NEW development of the core SIP Protocol Use 
> > > > [email-masked] for questions on
> > > current sip Use
> > > This list is for NEW development of the core SIP Protocol Use 
> > > [email-masked] for questions on current sip Use

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 4 Sep 2003 14:41:59 +0200

> You cannot make that conclusion.

Yes, I can
>I belong to operator1.com 
> that gave me this number 12345 as my telephone number. You 
> are with operator2 and they gave you the sip address 
> [email-masked]
> 
> Now, someone, not you, from operator2.com (your operator) 
> wants to call me. They dial 12345. Using your logic, your 
> phone ends up ringing instead of mine.

Correct, if I am in [email-masked] and you are in [email-masked] and someone
dials
32 in foo.bar, your phone rings. To get my phone ringing you either have
to enter 
[email-masked] or you dial +4317978032 or YOUR operator has agreed with my
operator on a short cut with an access code eg. 932 or **55 32.

This is called cross trunks or cross connections in PBX quack-speech and
established
since centuries.

Richard

> Sent: Thursday, September 04, 2003 2:26 PM
> > Sent: Thursday, September 04, 2003 3:15 PM
> > To: Khartabil Hisham (NMP/Helsinki); 
> [email-masked]; 
> You cannot make that conclusion. I belong to operator1.com 
> that gave me this number 12345 as my telephone number. You 
> are with operator2 and they gave you the sip address 
> [email-masked]
> 
> Now, someone, not you, from operator2.com (your operator) 
> wants to call me. They dial 12345. Using your logic, your 
> phone ends up ringing instead of mine.
> 
> /Hisham
> 
> > 
> > within my context I can be "dialed" also with 32. The E.164 number
> > mapped with 
> > > > I do not really understand this discussion, because 
> IMHO not even 
> > > > ;user=phone is necessary, not to talk about any
> > additional
> > > > parameters.
> > > > 
> > > > If you use an UAC where you may enter a complete sip: URI the 
> > > > INVITE is forwarded to the proper domain as is.
> > > > 
> > > > If it support numbers, it first checks if the number is 
> used as an 
> > > > alias for a user (e.g. 10000 for jeff)
> > > > 
> > > > If this is not the case, it may be a dialstring e.g. 
> (**7476691290 
> > > > for a sipphone user)
> > > > 
> you dial 
> > > > 17476691290 for own users (=alias), but 139310000
> > > for FWD and
> the phone 
> > > > is sending sip:[email-masked]
> > > > You normally can use only one local dialing plan as 
> default (same 
> > > > as in the PSTN).
> > > > 
> > > > > global-phone-number, according to RFC2806(or bis). I 
> don't think 
> > > > > there would be any backward compability issues, 
> because I doubt 
> > > > > anyone is using "+" for any other purpose - at least 
> not as the 
> > > > > first character of the user part. Of course, nodes 
> that really 
> > > > > REQUIRE user=phone to be present, in order to accept 
> the request 
> > > > > in the first, place would have to be changed.
> > > > > 
> > > > > Of course, user=tel could also be used, but I really 
> see no use 
> > > > > for that if the "+" rule applies. Also, user=tel COULD cause 
> > > > > backward compability issues.
> > > > > 
> > > > > user=phone really means, related BOTH to the userpart 
> syntax and 
> > > > > the message routing, we could remove it completely.
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Christer Holmberg
> > > > > Ericsson Finland
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > existing implementation seem to follow. If the 
> userinfo begins 
> > > > > > with "+" or contains a phone-context, then it is 
> reasonable to
> > > > interpret it as a
> > > > > > Actually, I believe it is reasonable to take the 
> SIP URL host 
> > > > > > part as the 'default'

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 4 Sep 2003 17:07:17 +0200

Hi,

I don't think the biggest issue is how terminals build the Request-URI.

The problem, I think, is when a server (especially gateways) receive the Request-URI. If the server receives a SIP-URI, and there is a "+", or visual separators, in the userpart, the server needs to know how to handle those.

I also think it's a little dangerous to say that a terminal must use tel-url if it sends a dial string. Will that work in call redirection cases, will it work in call forwarding cases, etc etc etc? In other words, are there cases the terminal simply must use a SIP-URI?

Regards,

Christer Holmberg
Ericsson Finland

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 4. syyskuuta 2003 17:25
> To: Christer Holmberg (JO/LMF)
> Cc: 'Bob Penfield'; [email-masked]
> I disagree with some of the details below, but some points are good.
> 
> First, the rules about who can interpret the userpart of a 
> sip url apply 
> regardless of whether user=phone is present or not. So nobody 
> should be 
> rejecting a sip url because of perceived problems with the 
> userpart if 
> it isn't their domain.
> 
> Included in the above is construction of sip uris by phones. 
> You have no 
> business transforming dialed digits into a sip uri unless you are 
> prepared to play by the rules of the domain you stick in that 
> uri. Since 
> the domain is probably provisioned into the phone, at that 
> time you had 
> better ensure that the phone can play by the rules for that domain.
> 
> That should take care of most issues of 2543 vs 3261/2806bis.
> 
> However, for the same reasons I think it preferable for phones to use 
> tel: urls. The reason is that sip urls from other domains can't be 
> deconstructed to provide reasonable displays on devices that deal 
> primarily with numbers.
> 
> Compatibility of various versions telephone-subscriber could be a 
> problem when dealing with tel urls. The usual guideline to be 
> strict in 
> what you send and forgiving of what you receive should apply here and 
> ought to be sufficient.
> 
> 	Paul
> 
> Christer Holmberg (JO/LMF) wrote:
> > Hi,
> > 
> >>interoperability problems are a result of that fact that what 
> >>is a valid
> >>userinfo part of a SIP URL with a user=phone parameter has 
> >>steadily gotten

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 11 Sep 2003 16:26:59 +0200

Hi,

So, is Bob's proposal something which could be accepted, or at least worked futher on?

Regards,

Christer Holmberg
Ericsson Finland

> Sent: 4. syyskuuta 2003 13:14

---

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Fri, 12 Sep 2003 10:14:14 -0400

Inline [RRR]

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Friday, September 12, 2003 9:03 AM
To: Bob Penfield
Cc: [email-masked]
Subject: Re: [Sip] SIPIT Interop problem with ;user=phone
....

Perhaps they both have their place. But if we are to have interop 
between phones of one vendor and severs of another, then we must 
eventually agree on how phones map dial strings to something that 
servers can process.

[RRR] I would also think so, even if we have to sacrifice some backward
compatibility issues (backward compatibility issues are dragging us too
much). 

[RRR] Which one is of more importance: 1. Global interoperability that
is not only required for SIP, but also for all other applications that
have been used so long by all of us worldwide, or 2. Backward
compatibility that is being used in SIP now in a limited way for some
implementations?

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 15 Sep 2003 09:10:11 -0700

> Sent: Monday, September 15, 2003 06:58
> To: Audet, Francois [SC100:4K02:EXCH]
> Cc: 'Rosen, Brian'; 'Bob Penfield'; [email-masked]'

[ stuff deleted as it looks like we are in agreement ]

> I'm not sure about the "most" part. Some do, some don't. As spec is 
> currently written, the equivalence between tel and sip/user=phone is 
> only one way. (IF the userpart comes from a tel, then there 
> SHOULD be a 
> user=phone, but the presence of user=phone does not imply the 
> userpart 
> conforms to tel.)
> 
> I personally am happy with the more strict interpretation. But I am 
> trying to hold out an olive branch in order to reach a level 
> of agreement.

OK. It seems that we are in agreement. 

My suggestion is to ask the question to the group of is anybody
objects to make it explicit that user=phones means that the sip URI is
derived 
from a tel URI?

If the answer is no, then I think we can probably finally put this issue 
to rest. Otherwise, we need to rework the whole thing...

So... Does anybody strongly object to explicitly making the user=phone
atttribute mean that the SIP URI was derived from a tel URI?

> > Applying the rules of RFC3261/19.1.6 instead, we'd get:
> > 
> >         
> > sip:1234;phone-context=[email-masked];user=phone
> > 
> > Which (like the tel URI) specifically identifies the 
> dialing plan and 
> > does not require one DNS entry per dialling plan.
> 
> 
> I agree that this is also a fine usage.
> 
> But what is benefit of this over using the tel format and 
> then passing 
> the request to sip:foo.bar?

The tel URI format assumes that the proxy knows which proxy is aware of the
phone context
and tel URIs (it could be itself, or it could know which proxy to route
sessions to).  

The sip URI format lets you route it to a specific proxy that is aware of
the phone
context, potentially with "generic" SIP proxies in between that have no idea
how to route
based on phone contextes (or even tel URIs). T

They both have merits.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 15 Sep 2003 11:21:22 -0700

> Well this goes to the issue Paul and I have disagreed on.
> 
> I think the wording of the tel uri RFC is quite clear that 
> you can't pass a dial string in one.  You certainly can't 
> pass one with
> star and pound.   Therefore, I claim, there is no way to pass
> a dial string, unless you put it in a username on a SIP uri, 
> and denote that it is a dial string, for which a phone number 
> is a proper subset for most dial plans, by specifying user=phone.
> 
> Paul disagrees.  He thinks he can send a dial string in a tel 
> uri. Without some kind of resolution of that issue, we have a problem.

Let's not be too hung up on terminology. Yes indeed, a pure "dial string"
shall
not be included in a SIP URI (especially the pound and star).

However, it is valid to have a "number" in a tel URI who's format is
valid only under a specific context. That context could happen to be closely
linked to a "dialing plan", including the "6" prefix in an enterprise, or
the "00", "01" in a carrier network. I'm not sure we can call this a
"dial string" per se as there will be some sort of minimal processing done
by the phone anyways (including removing the star and pound).

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 25 Aug 2003 13:13:20 -0400

Yes, of course, my bad.  

We do need to point that out in the I-D.

Brian

> From: Adam Roach [mailto:[email-masked]]
> Sent: Monday, August 25, 2003 12:13 PM
> To: 'Rosen, Brian'; Adam Roach
> Cc: [email-masked]
> Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> Rosen, Brian [mailto:[email-masked]] writes:
> 
> > 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?  I'd propose to deprecate
> > that (use a tel uri), but allow it for backwards
> > compatibility
> 
> I don't think we want to deprecate it. As has been pointed
> out already, one of the reasons that people transform tel:
> URIs into SIP URIs is that tel: URIs have no inherent routing
> properties. Yes, TRIP can be used for routing purposes, but
> that information is typically site-specific, not global. Often,
> the originating party will want to have more say in where
> a call goes than that.
> 
> Consider:
> 
> Route: <sip:proxy1.example.com;lr>, <sip:proxy2.example.com;lr>,
>        <tel:+19725551212;lr>
> 
> Even if this made sense, I'm left at the mercy of proxy2's
> local routing logic with regards to who services my tel URI.
> Compare:
> 
> Route: <sip:proxy1.example.com;lr>, <sip:proxy2.example.com;lr>,
>        <sip:[email-masked];lr>
> 
> /a
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 26 Aug 2003 08:22:53 -0400

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.

Brian

> From: William Marshall [mailto:[email-masked]]
> Sent: Tuesday, August 26, 2003 7:22 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> 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,
> just for my understanding:
> 
> > 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.
> > 
> 
> 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
> 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: Cullen Jennings <[email-masked]>
Date: Wed, 27 Aug 2003 14:31:50 -0700

For better or worse, I think pretty much all GW do 2.

On 8/27/03 10:43, "Dean Willis" <[email-masked]> wrote:

> 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: Cullen Jennings <[email-masked]>
Date: Fri, 29 Aug 2003 07:53:42 -0700

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:

>> 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: [email-masked]
Date: Fri, 29 Aug 2003 18:31:12 +0300

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

Regards,
Hisham

---

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

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

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: ext Rohan Mahy [mailto:[email-masked]]
> Sent: Sunday, August 24, 2003 6:27 PM
> To: Cullen Jennings
> Cc: Robert Sparks; [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
> 
>

---

From: [email-masked]
Date: Thu, 18 Sep 2003 22:09:59 +0300

This discussion about the use of user=phone is not going anywhere. Let me list what people want to use it for:

1. to indicate that the userinfo part of a request-uri is really a tel-uri (Rohan): [email-masked];user=phone
2. to indicate that a tel-uri used to be in the request-uri and has been translated at some point by some proxy (Brian): [email-masked];user=thisusedtobeateluri
3. to indicate that a user has entered a dial string. The proxy needs to figure out if the digits need to be translated into a tel-URI. The UA does not have a dialling plan: [email-masked];user=phone

Also there are issues of who should have dialling plans. What use cases require the UA to have dialling plans?

Regards,
Hisham

> Sent: Thursday, September 18, 2003 7:05 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> On Thu, 18 Sep 2003 [email-masked] wrote:
> 
> >
> >
> > > Sent: Wednesday, September 17, 2003 7:35 PM
> > > To: Khartabil Hisham (NMP-MSW/Helsinki)
> > > Cc: [email-masked]; [email-masked]; 
> [email-masked];
> > > [email-masked]; [email-masked]
> > > On Tuesday, September 16, 2003, at 11:27 PM,
> > > <[email-masked]> wrote:
> > >
> > > > I afraid C has the same problem as B.
> > >
> > > No, it doesn't.  Nobody except a server authoritative for 
> mci.com is
> > > allowed to interpret that URI. This is very clear for SIP and SIPS
> > > URIs. We don't have this kind of restriction on tel URIs.
> >
> > Section 16.5 states:
> >
> > "If the domain of the Request-URI indicates a domain this element is
> >    not responsible for, the Request-URI MUST be placed into 
> the target
> >    set as the only target, and the element MUST proceed to 
> the task of
> >    Request Forwarding (Section 16.6)."
> >
> > Section 16.6 states (step 6):
> >
> > "A proxy MAY have a local policy that mandates that a request
> >          visit a specific set of proxies before being 
> delivered to the
> >          destination"
> >
> > and step 7:
> >
> > "The proxy MAY have a local policy to send the request to a
> >          specific IP address, port, and transport, 
> independent of the
> >          values of the Route and Request-URI"
> >
> > Using your example C below, there is nothing restricting 
> transcoder.com from forwarding the request to att.com even if 
> the request-URI is a sip URI. Its transcoder.com local policy.
> 
> 
> agreed, there is nothing retricting trasncoder.com sending 
> the request to
> att.com, but att.com then needs to forward this request on 
> the mci.com.
> att.com does not get to process the userpart of a URI which ends in
> mci.com.  (unless they buy them  ;-)
> 
> however, in case B, att.com could just process the tel URI in 
> the request
> URI and never send the request to mci.com.
> 
> thanks,
> -rohan
> 
> 
> > /Hisham
> >
> > >
> > > thanks,
> > > -rohan
> > >
> > > > /Hisham
> > > >
> > > >
> > > >> Sent: Tuesday, September 16, 2003 7:27 PM
> > > >> To: Robert Sparks
> > > >> Cc: Paul Kyzivat; Adam Roach; 'Rosen, Brian'; [email-masked]
> > > >> On Tuesday, September 16, 2003, at 07:01 AM, Robert 
> Sparks wrote:
> > > >>
> > > >>> On Fri, 2003-09-12 at 13:18, Rohan Mahy wrote:
> > > >>>
> > > >>>> While I do not object to sending tel URIs to SIP proxies,
> > > >> I believe I
> > > >>>> already articulated some reasons why you might want to use
> > > >> sip or sips
> > > >>>> instead.
> > > >>>>
> > > >>>> 1) want to use SIPS
> > > >>>
> > > >>> Agreed!
> > > >>>
> > > >>>> 2) want to route the call to a specific domain that is not
> > > >> the domain
> > > >>>> of your first hop proxy.
> > > >>>> 3) want to invoke a loose router for services like
> > > >> transcoding or call
> > > >>>> history logging that have different tel URI handling
> > > rules than you
> > > >>>> want to use.
> > > >>>
> > > >>> Both 2 and 3 can be solved by pushing or preloading routes.
> > > >>
> > > >> OK, I was being sloppy.  Looking at several options.
> > > >>
> > > >> A.
> > > >> 	INVITE tel:+14085264000 SIP/2.0
> > > >> 	Route: <sip:transcoders.com;lr>
> > > >>
> > > >> A is not so good, because you have no control over what
> > > >> transcoders.com
> > > >> does with tel URLs  (It might reject them, or send you 
> a big bill).
> > > >>
> > > >> B.
> > > >>
> > > >> 	INVITE tel:+14085264000 SIP/2.0
> > > >> 	Route: <sip:transcoders.com;lr>, <sip:mci.com;lr>
> > > >>
> > > >> B would probably work, but seems much more cumbersome 
> than C.  In
> > > >> addition, transcoders.com might forward all calls 
> toward mci.com
> > > >> through some other domain (att.com) which might just take
> > > the tel URL
> > > >> and process it itself.
> > > >>
> > > >> C.
> > > >>
> > > >> 	INVITE sip:[email-masked];user=phone SIP/2.0
> > > >> 	Route: <sip:transcoders.com;lr>
> > > >>
> > > >> C is explicit, it works, and it contains no extra info.
> > > >>
> > > >> thanks,
> > > >> -rohan
> > > >>
> > > >>
> current sip

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 29 Aug 2003 07:50:49 -0700

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Aug 2003 11:12:35 -0500

Consider:

/a

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Sep 2003 13:37:22 -0400

Richard

My phone number within my local domain is 742-6826.
I could change the convention and make it 724-742-6826 or
1-724-742-6826 if you want.

My dial plan would send a call to a different phone if you
dialed any of those strings.

If you send an INVITE [email-masked] it will ring
my sipphone.  

If I dial 7426826, it won't ring my sip phone.  I have to dial
6826 or 9-742-6826  or even 300-6826.

Using your algorithm, I would assume 7426826 was a dial string,
and that would be wrong.

Brian

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Friday, September 19, 2003 1:24 PM
> To: Rosen, Brian; Rohan Mahy
> Cc: Francois Audet; Paul Kyzivat; Bob Penfield; [email-masked]
> Subject: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> See below
> 
> 	Von: Rosen, Brian [mailto:[email-masked]] 
> 	Gesendet: Fr 19.09.2003 15:17 
> 	An: 'Rohan Mahy' 
> 	Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; 
> [email-masked]' 
> 	Betreff: RE: [Sip] SIPIT Interop problem with ;user=phone
> 	
> 	
> 
> 	I've never seen E/F substitution for */#, and I've 
> never seen any
> 	sip device that did it, but it's a possible way forward.
> 	
> 	I do think that some RFC would have to change the wording of
> 	2806bis to allow dial strings.  The authors seemed to explicitly
> 	declare them out of scope of the document.  Generally, we don't
> 	usually claim "that which is not specifically 
> disallowed is legal"
> 	as a way around "out of scope" wording in our documents.
> 	
> 	I remain unhappy that dial strings, untranslated phone numbers
> 	and translated phone numbers are indistinguishable.  
> They are different,
> 	they are handled differently, and they should be 
> distinguishable.
> 	I don't understand why some people are so adamant that 
> they should all
> 	be represented in EXACTLY the same way (tel uri or sip uri with
> 	or without user=phone).  They are not the same things, and they
> 	should have distinctive representations.
> 
> Richard: A string of digits is a string of digits.
> 
> The simplest way to distinguish is:
> 
> 1. If you just see a string of digits, you have to assume its 
> a dial string
> 
> until you know better.
> 
> 2. If you analysed the digits and found out its an E.164 
> number, normalise it
> 
> to tel:+xxxx, or sip:[email-masked]
> 
> 3. If you analysed it and found out it is a local number, then either
> 
> use tel:xxxx; phone-context=foo.bar or sip:[email-masked];user=phone
> 
> I do not understand the problem
> 
> Richard
> 
> 	
> 	
> 	Brian
> 	
> 	> From: Rohan Mahy [mailto:[email-masked]]
> 	> Sent: Thursday, September 18, 2003 9:17 PM
> 	> To: Rosen, Brian
> 	> Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; 
> [email-masked]'
> 	> On Monday, September 15, 2003, at 10:23 AM, Rosen, 
> Brian wrote:
> 	> > I think the wording of the tel uri RFC is quite 
> clear that you
> 	> > can't pass a dial string in one.  You certainly 
> can't pass one with
> 	> > a dial string
> 	> Brian,  What part of a dial string doesn't fit into: 
> 1*phonedigit   ?
> 	>
> 	> phonedigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
> 	> "8" / "9" /
> 	>               "A" / "B" / "C" / "D" / "E" / "F"
> 	>
> 	> E corresponds to *  and F corresponds to #
> 	>
> 	> thanks,
> 	> -rohan
> 	>
> 	>
> 	> > , unless you put it in a username on a SIP uri,
> 	> > and denote that it is a dial string, for which a 
> phone number is
> 	> > a proper subset for most dial plans, by specifying 
> user=phone.
> 	> >
> 	> > Paul disagrees.  He thinks he can send a dial 
> string in a tel uri.
> 	> > Without some kind of resolution of that issue, we 
> have a problem.
> 	> >
> 	> > Brian
> 	> > From: Francois Audet [mailto:[email-masked]]
> 	> > Sent: Monday, September 15, 2003 12:10 PM
> 	> > To: 'Paul Kyzivat'
> 	> > If the answer is no, then I think we can probably 
> finally put this
> 	> > issue
> 	> > The tel URI format assumes that the proxy knows which proxy
> 	> is aware
> 	> > of the
> 	> > phone context
> 	> > The sip URI format lets you route it to a specific proxy
> 	> that is aware
> 	> > of
> 	> > the phone
> 	> > context, potentially with "generic" SIP proxies in between
> 	> that have
> 	> > no idea
> 	> > how to route

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 19 Sep 2003 19:23:39 +0200

See below

	-----Ursprüngliche Nachricht----- 
	Von: Rosen, Brian [mailto:[email-masked]] 
	Gesendet: Fr 19.09.2003 15:17 
	An: 'Rohan Mahy' 
	Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; [email-masked]' 
	Betreff: RE: [Sip] SIPIT Interop problem with ;user=phone

	I've never seen E/F substitution for */#, and I've never seen any
	sip device that did it, but it's a possible way forward.
	
	usually claim "that which is not specifically disallowed is legal"
	
	I remain unhappy that dial strings, untranslated phone numbers
	and translated phone numbers are indistinguishable.  They are different,
	they are handled differently, and they should be distinguishable.
	I don't understand why some people are so adamant that they should all
	be represented in EXACTLY the same way (tel uri or sip uri with
	or without user=phone).  They are not the same things, and they
	should have distinctive representations.

1. If you just see a string of digits, you have to assume its a dial string

until you know better.

2. If you analysed the digits and found out its an E.164 number, normalise it

Richard

	Brian
	
	> Cc: 'Francois Audet'; 'Paul Kyzivat'; 'Bob Penfield'; [email-masked]'
	> On Monday, September 15, 2003, at 10:23 AM, Rosen, Brian wrote:
	> > I think the wording of the tel uri RFC is quite clear that you
	> > can't pass a dial string in one.  You certainly can't pass one with
	> Brian,  What part of a dial string doesn't fit into: 1*phonedigit   ?
	>
	> > and denote that it is a dial string, for which a phone number is
	> > a proper subset for most dial plans, by specifying user=phone.
	> >
	> > Paul disagrees.  He thinks he can send a dial string in a tel uri.
	> > Without some kind of resolution of that issue, we have a problem.
	> >
	> > Brian

����X��X��m����5��_��?�������+-�w��ȩN��+-����u�ޖ�fz{h~�^r��H�Ϯ�hr�T��"�)��鞞�+���[�n&�v�讫��ب��'r��z{l��,zȩ�)���_������ׯzZ)������橦X�jب���

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 19 Sep 2003 10:37:14 -0700

I really don't think our positions are that different.

I think a way forward would be to alter the offending statement 
that dial string are "not allowed" (because it is essentially
contradicted in 2806bis when it explains how to do phone-contextes).

Instead of saying that dial string are not allowed, we should
explicitly describe that dial string can be implemented
by defining a phone-context for that purpose (i.e., for a 
specific dial plan). That should realign Brian's view with Paul's and mine's

that dial string are implementable today with 2806-bis.

On the specific issue of * and #, I had never heard either about the E/F
substitution (in fact, I tought it was an ISUP thing). Regardless,
I don't have any problem with adding * and # (explicitly or with E/F
substitution), as long as it is done with the phone-context
mechanism for a dialing plan.

If we can agree to that, I guess we'll have to move this to IPTEL
for 2806-bis.

> From: Rosen, Brian [mailto:[email-masked]] 
> Sent: Friday, September 19, 2003 06:18
> To: 'Rohan Mahy'
> Cc: Audet, Francois [SC100:4K02:EXCH]; 'Paul Kyzivat'; 'Bob 
> Penfield'; [email-masked]'
> I've never seen E/F substitution for */#, and I've never seen 
> any sip device that did it, but it's a possible way forward.
> 
> 2806bis to allow dial strings.  The authors seemed to 
> explicitly declare them out of scope of the document.  
> Generally, we don't usually claim "that which is not 
> specifically disallowed is legal" as a way around "out of 
> scope" wording in our documents.
> 
> I remain unhappy that dial strings, untranslated phone 
> numbers and translated phone numbers are indistinguishable.  
> They are different, they are handled differently, and they 
> should be distinguishable. I don't understand why some people 
> are so adamant that they should all be represented in EXACTLY 
> the same way (tel uri or sip uri with or without user=phone). 
>  They are not the same things, and they should have 
> distinctive representations.
> 
> Brian 
> 
> > > I think the wording of the tel uri RFC is quite clear 
> that you can't 
> > > pass a dial string in one.  You certainly can't pass one with
> > > and denote that it is a dial string, for which a phone 
> number is a 
> > > proper subset for most dial plans, by specifying user=phone.
> > >
> > >> only one way. (IF the userpart comes from a tel, then 
> there SHOULD 
> > >> be a user=phone, but the presence of user=phone does not 
> imply the
> > >> userpart
> > >> conforms to tel.)
> > >>
> > >> trying to hold out an olive branch in order to reach a level of 
> > >> agreement.
> > >> But what is benefit of this over using the tel format and then 
> > >> passing the request to sip:foo.bar?

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 19 Sep 2003 08:26:49 -0700

I agree.

> Sent: Thursday, September 18, 2003 18:20
> To: Rosen, Brian
> Cc: Audet, Francois [SC100:4K02:EXCH]; 'Bob Penfield'; 'Paul 
> Kyzivat'; [email-masked]'
> On Monday, September 15, 2003, at 11:40 AM, Rosen, Brian wrote:
> 
> > I'm sorry, but when the draft says:
> > "Dial strings are beyond the scope of this document."
> > to me, means dial string is not legal in a tel uri.
> 
> To me this statement simply means that the *internal 
> semantics* of dial 
> strings are not defined in that document.  It does not say  "you MUST 
> not put a dial string into the phone-number portion of a local-number"
> 
> Perhaps it should say that no special considerations for dial strings 
> are included in the document.  Specifically wait and pause 
> are missing, 
> but that is not what you are describing.
> 
> thanks,
> -rohan

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 19 Sep 2003 15:04:32 -0700

That's the point: you can only do that if you use a phone-context.

The phone-context reflects the user's dialing plan (the user
MAKING the phone call, not the destination).

So you deploy a bunch of dumb phones (let's say numbering-plan unaware
phones to be more accurate) in Chicago, and you make sure that they
are all configured with "phone-context=chicago.proxy.com". Presumably
IS would make sure that it is pre-configured somehow so that the user
doesn't have to do it manually.

> Sent: Friday, September 19, 2003 15:04
> To: Audet, Francois [SC100:4K02:EXCH]; Rosen, Brian; Rohan Mahy
> Cc: Paul Kyzivat; Bob Penfield; [email-masked]
> I understand your example, but I thought we are talking
> about dunb UA without having dialing plans built in.
>  
> How do you tell your phone to send append in one case 
> santaclara.proxy.com and in the other case chicago.proxy.com 
> if you just dial 3756?
>  
> Either you use an access code, but then you have
> a dialing plan built in, or you sent it with the
> access code to the default proxy and let it doing the work,
>  
> or you use separate lines and swich between them.
>  
>

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 20 Sep 2003 00:28:28 +0200

SSB0aGluayB3ZSBhcmUgdGFsa2luZyB0aGUgc2FtZSB0aGluZywgSSBhZ3JlZS4NCiANCkJ1dCwgSSBzdGlsbCBkbyBub3Qgc2VlIHdoeSB5b3UgbmVlZA0KIA0KMS4gO3VzZXI9cGhvbmUNCjIuIDtwaG9uZS1jb250ZXh0PWNoaWNhZ28ucHJveHkuY29tIHdpdGhpbiB0aGUgc2lwOiBVUkkNCiANClRoZSBwaG9uZS1jb250ZXh0IGlzIG5lY2Vzc2FyeSBpbiB0aGUgdGVsOiBVUkkgYmVjYXVzZSB0aGVyZSBpcyBubyBvdGhlciB3YXkNCnRvIGluZGljYXRlIGEgY29udGV4dCAoYmVzaWRlIG9mIHVzaW5nIGFjY2VzcyBjb2RlcyksDQpidXQgaW4gd2l0aCBzaXA6Mzc1NkBjaGljYWdvLnByb3h5LmNvbSBhbmQgc2lwOnNhbnRhY2xhcmEucHJveHkuY29tDQp5b3UgY291bGQgYWxzbyBwb2ludCB0byB0aGUgU0FNRSBwcm94eSwgc28gcGhvbmUtY29udGV4dD1jaGljYWdvLnByb3h5LmNvbQ0KaXMgcmVkdW5kYW50IChidXQgaXQgZG9lcyBub3QgaHVydCwgb24gdGhlIG90aGVyIHNpZGUgOy0pDQogDQpSaWNoYXJkDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogRnJhbmNvaXMgQXVkZXQgW21haWx0bzphdWRldEBub3J0ZWxuZXR3b3Jrcy5jb21dIA0KCUdlc2VuZGV0OiBTYSAyMC4wOS4yMDAzIDAwOjA0IA0KCUFuOiBTdGFzdG55IFJpY2hhcmQ7ICdSb3NlbiwgQnJpYW4nOyAnUm9oYW4gTWFoeScgDQoJQ2M6ICdQYXVsIEt5eml2YXQnOyAnQm9iIFBlbmZpZWxkJzsgJ3NpcEBpZXRmLm9yZycgDQoJQmV0cmVmZjogUkU6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lDQoJDQoJDQoNCglUaGF0J3MgdGhlIHBvaW50OiB5b3UgY2FuIG9ubHkgZG8gdGhhdCBpZiB5b3UgdXNlIGEgcGhvbmUtY29udGV4dC4gDQoNCglUaGUgcGhvbmUtY29udGV4dCByZWZsZWN0cyB0aGUgdXNlcidzIGRpYWxpbmcgcGxhbiAodGhlIHVzZXIgDQoJTUFLSU5HIHRoZSBwaG9uZSBjYWxsLCBub3QgdGhlIGRlc3RpbmF0aW9uKS4gDQoNCglTbyB5b3UgZGVwbG95IGEgYnVuY2ggb2YgZHVtYiBwaG9uZXMgKGxldCdzIHNheSBudW1iZXJpbmctcGxhbiB1bmF3YXJlIA0KCXBob25lcyB0byBiZSBtb3JlIGFjY3VyYXRlKSBpbiBDaGljYWdvLCBhbmQgeW91IG1ha2Ugc3VyZSB0aGF0IHRoZXkgDQoJYXJlIGFsbCBjb25maWd1cmVkIHdpdGggInBob25lLWNvbnRleHQ9Y2hpY2Fnby5wcm94eS5jb20iLiBQcmVzdW1hYmx5IA0KCUlTIHdvdWxkIG1ha2Ugc3VyZSB0aGF0IGl0IGlzIHByZS1jb25maWd1cmVkIHNvbWVob3cgc28gdGhhdCB0aGUgdXNlciANCglkb2Vzbid0IGhhdmUgdG8gZG8gaXQgbWFudWFsbHkuIA0KDQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCgk+IEZyb206IFN0YXN0bnkgUmljaGFyZCBbbWFpbHRvOlJpY2hhcmQuU3Rhc3RueUBvZWZlZy5hdF0gDQoJPiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxOSwgMjAwMyAxNTowNCANCgk+IFRvOiBBdWRldCwgRnJhbmNvaXMgW1NDMTAwOjRLMDI6RVhDSF07IFJvc2VuLCBCcmlhbjsgUm9oYW4gTWFoeSANCgk+IENjOiBQYXVsIEt5eml2YXQ7IEJvYiBQZW5maWVsZDsgc2lwQGlldGYub3JnIA0KCT4gU3ViamVjdDogQVc6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lIA0KCT4gDQoJPiANCgk+IEkgdW5kZXJzdGFuZCB5b3VyIGV4YW1wbGUsIGJ1dCBJIHRob3VnaHQgd2UgYXJlIHRhbGtpbmcgDQoJPiBhYm91dCBkdW5iIFVBIHdpdGhvdXQgaGF2aW5nIGRpYWxpbmcgcGxhbnMgYnVpbHQgaW4uIA0KCT4gIA0KCT4gSG93IGRvIHlvdSB0ZWxsIHlvdXIgcGhvbmUgdG8gc2VuZCBhcHBlbmQgaW4gb25lIGNhc2UgDQoJPiBzYW50YWNsYXJhLnByb3h5LmNvbSBhbmQgaW4gdGhlIG90aGVyIGNhc2UgY2hpY2Fnby5wcm94eS5jb20gDQoJPiBpZiB5b3UganVzdCBkaWFsIDM3NTY/IA0KCT4gIA0KCT4gRWl0aGVyIHlvdSB1c2UgYW4gYWNjZXNzIGNvZGUsIGJ1dCB0aGVuIHlvdSBoYXZlIA0KCT4gYSBkaWFsaW5nIHBsYW4gYnVpbHQgaW4sIG9yIHlvdSBzZW50IGl0IHdpdGggdGhlIA0KCT4gYWNjZXNzIGNvZGUgdG8gdGhlIGRlZmF1bHQgcHJveHkgYW5kIGxldCBpdCBkb2luZyB0aGUgd29yaywgDQoJPiAgDQoJPiBvciB5b3UgdXNlIHNlcGFyYXRlIGxpbmVzIGFuZCBzd2ljaCBiZXR3ZWVuIHRoZW0uIA0KCT4gIA0KCT4gDQoNCg==_______________________________________________Sip mailing list  https://www1.ietf.org/mailman/listinfo/sipThis list is for NEW development of the core SIP ProtocolUse [email-masked] for questions on current sipUse [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 19 Sep 2003 14:56:56 -0700

> This is exactly the point that I was trying to make much 
> earlier in this thread. 
> 
> That if ";user=phone" means that the username came from a 
> tel: URL, it does NOT (repeat NOT) mean that anyone else in 
> the path can convert it back to a tel: URL and process it.  
> It will only be handled by a proxy responsible for the domain 
> named in the sip: URL.
> 
> Past proposed wordings that the request would only be handled by 
> proxies that "understand the username part" still concern me, 
> because ";user=phone" (if the resolution here is that it 
> means exactly a tel: URL) could give anyone that 
> understanding.  Routing still must be to the domain named in 
> the request-URI, whether 
> ";user=phone" is present or not.  I'm fairly certain this 
> point has been agreed by all parties.

Agreed.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 19 Sep 2003 15:42:44 -0700

> I think we are talking the same thing, I agree.
>  
> But, I still do not see why you need
>  
> 1. ;user=phone
> 2. ;phone-context=chicago.proxy.com within the sip: URI
>  
> The phone-context is necessary in the tel: URI because there 
> is no other way to indicate a context (beside of using access 
> codes), but in with sip:[email-masked] and 
> sip:santaclara.proxy.com you could also point to the SAME 
> proxy, so phone-context=chicago.proxy.com is redundant (but 
> it does not hurt, on the other side ;-)

You could put a single proxy (proxy.com) in the headquarter in
Vienna. The dialing plans could all be stored on that proxy.]

The local office in Chicago wouldn't not have any proxies who
understand dialing plan.

Chicago makes a call to Paris. User dials 6011-33-12-14-16-18.

It's phone takes the dial digits (60113312141618) and, appends
its phone-context for dial digits, constructs the URI and fires
it off to the proxy in Vienna. The URI will be as follows:
- tel:60113312141618;phone-context=chicago.proxy.com

The only thing the phone needs to understand for this is that 
the it needs to include the phone-context. I'm assuming a phone
that does not do any digit parsing (i.e., the "dumb" phone).

The Vienna proxy will figure out how to parse the digits based 
on the phone-contex=chicago.proxy.com (and thus figure out that
6011 means dial outside the PBX to an international number.

The equivalent SIP URI would be 
- sip:60113312141618;phone-context=[email-masked];user=phone

The domain name doesn't have to match the phone-context. For example, 
the phone service could be handled by isp.net, in which case the URI
could be:
- sip:60113312141618;phone-context=[email-masked];user=phone

In other words, the phone should be configurable with both the domain name 
(in this example isp.net) and the phone-context (in this case
chicago.proxy.com).

In a lot of simple cases, it is very likely that a small enterprise
could just use the same value for the phone-context (mysmallbusiness.com)
as the proxy (mysmallbusiness.com).

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Sep 2003 15:50:35 -0500

> and translated phone numbers are indistinguishable.

Perhaps we should require them to have some method of distinguishing
them. Maybe... oh, I don't know... including a "phone-context=something"
as part of the dial string. Maybe we could even include "+" as the
first character as a shorthand way to indicate that the digits are
already translated to be fully internationalized.

Which sounds to me like status quo for what's actually written down.

/a

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 19 Sep 2003 21:33:11 +0200

QnJpYW4sDQogDQpJZiB5b3UgcGljayB1cCBhIHBob25lIGFuZCBlbnRlciBkaWdpdHMsIGl0IEFMV0FZUyBhIGRpYWxpbmcgc3RyaW5nDQphbmQgeW91IGFyZSBBTFdBWVMgaW4gT05FIGFuZCBPTkxZIE9ORSBkaWFsaW5nIHBsYW4uLg0KIA0KWW91IG5ldmVyIGVudGVyIGEgcGhvbmUgbnVtYmVyIGRpcmVjdGx5LCB5b3UgYWx3YXlzDQpkaWFsIChpZiB5b3UgZGlhbCBhIGxvY2FsIG51bWJlciwgdGhlIG1hcHBpbmcgbWF5IGJlIDE6MSkNCiANClNvIGlmIHlvdSBlbnRlciBhIGRpYWwgc3RyaW5nIGluIGEgU0lQIHBob25lIGFuZCBpdSBzZW5kcw0KaXQgd2l0aCBubm5uQGRlZmF1bHQuY29tIHRvIHlvdXIgZGVmYXVsciBzaXAgc2VydmVyLCB0aGlzIHNlcnZlcg0KdGhlbiBldmFsdWF0ZXMgdGhlIGRpYWxpbmcgcGxhbiBhbmQgdHJhbnNsYXRlcyBpdCB0byBhIG51bWJlcmluZyBwbGFuLg0KIA0KQnR3LCB0aGF0cyBleGFjdGx5IGhvdyBmd2QsIGlwdGVsIHNpcHBob25lLCAuLi4gYXJlIGltcGxlbWV0ZWQuDQogDQpSaWNoYXJkDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogUm9zZW4sIEJyaWFuIFttYWlsdG86QnJpYW4uUm9zZW5AbWFyY29uaS5jb21dIA0KCUdlc2VuZGV0OiBGciAxOS4wOS4yMDAzIDE5OjM3IA0KCUFuOiBTdGFzdG55IFJpY2hhcmQ7IFJvaGFuIE1haHkgDQoJQ2M6IEZyYW5jb2lzIEF1ZGV0OyBQYXVsIEt5eml2YXQ7IEJvYiBQZW5maWVsZDsgc2lwQGlldGYub3JnIA0KCUJldHJlZmY6IFJFOiBbU2lwXSBTSVBJVCBJbnRlcm9wIHByb2JsZW0gd2l0aCA7dXNlcj1waG9uZQ0KCQ0KCQ0KDQoJUmljaGFyZA0KCQ0KCU15IHBob25lIG51bWJlciB3aXRoaW4gbXkgbG9jYWwgZG9tYWluIGlzIDc0Mi02ODI2Lg0KCUkgY291bGQgY2hhbmdlIHRoZSBjb252ZW50aW9uIGFuZCBtYWtlIGl0IDcyNC03NDItNjgyNiBvcg0KCTEtNzI0LTc0Mi02ODI2IGlmIHlvdSB3YW50Lg0KCQ0KCU15IGRpYWwgcGxhbiB3b3VsZCBzZW5kIGEgY2FsbCB0byBhIGRpZmZlcmVudCBwaG9uZSBpZiB5b3UNCglkaWFsZWQgYW55IG9mIHRob3NlIHN0cmluZ3MuDQoJDQoJSWYgeW91IHNlbmQgYW4gSU5WSVRFIDc0MjY4MjZAcGl0LnNpcC5tYXJjb25pLmNvbSBpdCB3aWxsIHJpbmcNCglteSBzaXBwaG9uZS4gDQoJDQoJSWYgSSBkaWFsIDc0MjY4MjYsIGl0IHdvbid0IHJpbmcgbXkgc2lwIHBob25lLiAgSSBoYXZlIHRvIGRpYWwNCgk2ODI2IG9yIDktNzQyLTY4MjYgIG9yIGV2ZW4gMzAwLTY4MjYuDQoJDQoJVXNpbmcgeW91ciBhbGdvcml0aG0sIEkgd291bGQgYXNzdW1lIDc0MjY4MjYgd2FzIGEgZGlhbCBzdHJpbmcsDQoJYW5kIHRoYXQgd291bGQgYmUgd3JvbmcuDQoJDQoJQnJpYW4NCgkNCgk+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiBGcm9tOiBTdGFzdG55IFJpY2hhcmQgW21haWx0bzpSaWNoYXJkLlN0YXN0bnlAb2VmZWcuYXRdDQoJPiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxOSwgMjAwMyAxOjI0IFBNDQoJPiBUbzogUm9zZW4sIEJyaWFuOyBSb2hhbiBNYWh5DQoJPiBDYzogRnJhbmNvaXMgQXVkZXQ7IFBhdWwgS3l6aXZhdDsgQm9iIFBlbmZpZWxkOyBzaXBAaWV0Zi5vcmcNCgk+IFN1YmplY3Q6IEFXOiBbU2lwXSBTSVBJVCBJbnRlcm9wIHByb2JsZW0gd2l0aCA7dXNlcj1waG9uZQ0KCT4NCgk+DQoJPiBTZWUgYmVsb3cNCgk+DQoJPiAgICAgICAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQoJPiAgICAgICBWb246IFJvc2VuLCBCcmlhbiBbbWFpbHRvOkJyaWFuLlJvc2VuQG1hcmNvbmkuY29tXQ0KCT4gICAgICAgR2VzZW5kZXQ6IEZyIDE5LjA5LjIwMDMgMTU6MTcNCgk+ICAgICAgIEFuOiAnUm9oYW4gTWFoeScNCgk+ICAgICAgIENjOiAnRnJhbmNvaXMgQXVkZXQnOyAnUGF1bCBLeXppdmF0JzsgJ0JvYiBQZW5maWVsZCc7DQoJPiAnc2lwQGlldGYub3JnJw0KCT4gICAgICAgQmV0cmVmZjogUkU6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lDQoJPiAgICAgIA0KCT4gICAgICANCgk+DQoJPiAgICAgICBJJ3ZlIG5ldmVyIHNlZW4gRS9GIHN1YnN0aXR1dGlvbiBmb3IgKi8jLCBhbmQgSSd2ZQ0KCT4gbmV2ZXIgc2VlbiBhbnkNCgk+ICAgICAgIHNpcCBkZXZpY2UgdGhhdCBkaWQgaXQsIGJ1dCBpdCdzIGEgcG9zc2libGUgd2F5IGZvcndhcmQuDQoJPiAgICAgIA0KCT4gICAgICAgSSBkbyB0aGluayB0aGF0IHNvbWUgUkZDIHdvdWxkIGhhdmUgdG8gY2hhbmdlIHRoZSB3b3JkaW5nIG9mDQoJPiAgICAgICAyODA2YmlzIHRvIGFsbG93IGRpYWwgc3RyaW5ncy4gIFRoZSBhdXRob3JzIHNlZW1lZCB0byBleHBsaWNpdGx5DQoJPiAgICAgICBkZWNsYXJlIHRoZW0gb3V0IG9mIHNjb3BlIG9mIHRoZSBkb2N1bWVudC4gIEdlbmVyYWxseSwgd2UgZG9uJ3QNCgk+ICAgICAgIHVzdWFsbHkgY2xhaW0gInRoYXQgd2hpY2ggaXMgbm90IHNwZWNpZmljYWxseQ0KCT4gZGlzYWxsb3dlZCBpcyBsZWdhbCINCgk+ICAgICAgIGFzIGEgd2F5IGFyb3VuZCAib3V0IG9mIHNjb3BlIiB3b3JkaW5nIGluIG91ciBkb2N1bWVudHMuDQoJPiAgICAgIA0KCT4gICAgICAgSSByZW1haW4gdW5oYXBweSB0aGF0IGRpYWwgc3RyaW5ncywgdW50cmFuc2xhdGVkIHBob25lIG51bWJlcnMNCgk+ICAgICAgIGFuZCB0cmFuc2xhdGVkIHBob25lIG51bWJlcnMgYXJlIGluZGlzdGluZ3Vpc2hhYmxlLiANCgk+IFRoZXkgYXJlIGRpZmZlcmVudCwNCgk+ICAgICAgIHRoZXkgYXJlIGhhbmRsZWQgZGlmZmVyZW50bHksIGFuZCB0aGV5IHNob3VsZCBiZQ0KCT4gZGlzdGluZ3Vpc2hhYmxlLg0KCT4gICAgICAgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBzb21lIHBlb3BsZSBhcmUgc28gYWRhbWFudCB0aGF0DQoJPiB0aGV5IHNob3VsZCBhbGwNCgk+ICAgICAgIGJlIHJlcHJlc2VudGVkIGluIEVYQUNUTFkgdGhlIHNhbWUgd2F5ICh0ZWwgdXJpIG9yIHNpcCB1cmkgd2l0aA0KCT4gICAgICAgb3Igd2l0aG91dCB1c2VyPXBob25lKS4gIFRoZXkgYXJlIG5vdCB0aGUgc2FtZSB0aGluZ3MsIGFuZCB0aGV5DQoJPiAgICAgICBzaG91bGQgaGF2ZSBkaXN0aW5jdGl2ZSByZXByZXNlbnRhdGlvbnMuDQoJPg0KCT4gUmljaGFyZDogQSBzdHJpbmcgb2YgZGlnaXRzIGlzIGEgc3RyaW5nIG9mIGRpZ2l0cy4NCgk+DQoJPiBUaGUgc2ltcGxlc3Qgd2F5IHRvIGRpc3Rpbmd1aXNoIGlzOg0KCT4NCgk+IDEuIElmIHlvdSBqdXN0IHNlZSBhIHN0cmluZyBvZiBkaWdpdHMsIHlvdSBoYXZlIHRvIGFzc3VtZSBpdHMNCgk+IGEgZGlhbCBzdHJpbmcNCgk+DQoJPiB1bnRpbCB5b3Uga25vdyBiZXR0ZXIuDQoJPg0KCT4gMi4gSWYgeW91IGFuYWx5c2VkIHRoZSBkaWdpdHMgYW5kIGZvdW5kIG91dCBpdHMgYW4gRS4xNjQNCgk+IG51bWJlciwgbm9ybWFsaXNlIGl0DQoJPg0KCT4gdG8gdGVsOit4eHh4LCBvciBzaXA6K3h4eHhAZm9vLmJhcg0KCT4NCgk+IDMuIElmIHlvdSBhbmFseXNlZCBpdCBhbmQgZm91bmQgb3V0IGl0IGlzIGEgbG9jYWwgbnVtYmVyLCB0aGVuIGVpdGhlcg0KCT4NCgk+IHVzZSB0ZWw6eHh4eDsgcGhvbmUtY29udGV4dD1mb28uYmFyIG9yIHNpcDp4eHhAZm9vLmJhcjt1c2VyPXBob25lDQoJPg0KCT4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbQ0KCT4NCgk+IFJpY2hhcmQNCgk+DQoJPiAgICAgIA0KCT4gICAgICANCgk+ICAgICAgIEJyaWFuDQoJPiAgICAgIA0KCT4gICAgICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4gICAgICAgPiBGcm9tOiBSb2hhbiBNYWh5IFttYWlsdG86cm9oYW5AY2lzY28uY29tXQ0KCT4gICAgICAgPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDE4LCAyMDAzIDk6MTcgUE0NCgk+ICAgICAgID4gVG86IFJvc2VuLCBCcmlhbg0KCT4gICAgICAgPiBDYzogJ0ZyYW5jb2lzIEF1ZGV0JzsgJ1BhdWwgS3l6aXZhdCc7ICdCb2IgUGVuZmllbGQnOw0KCT4gJ3NpcEBpZXRmLm9yZycNCgk+ICAgICAgID4gU3ViamVjdDogUmU6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lDQoJPiAgICAgICA+DQoJPiAgICAgICA+DQoJPiAgICAgICA+IE9uIE1vbmRheSwgU2VwdGVtYmVyIDE1LCAyMDAzLCBhdCAxMDoyMyBBTSwgUm9zZW4sDQoJPiBCcmlhbiB3cm90ZToNCgk+ICAgICAgID4gPiBXZWxsIHRoaXMgZ29lcyB0byB0aGUgaXNzdWUgUGF1bCBhbmQgSSBoYXZlIGRpc2FncmVlZCBvbi4NCgk+ICAgICAgID4gPg0KCT4gICAgICAgPiA+IEkgdGhpbmsgdGhlIHdvcmRpbmcgb2YgdGhlIHRlbCB1cmkgUkZDIGlzIHF1aXRlDQoJPiBjbGVhciB0aGF0IHlvdQ0KCT4gICAgICAgPiA+IGNhbid0IHBhc3MgYSBkaWFsIHN0cmluZyBpbiBvbmUuICBZb3UgY2VydGFpbmx5DQoJPiBjYW4ndCBwYXNzIG9uZSB3aXRoDQoJPiAgICAgICA+ID4gc3RhciBhbmQgcG91bmQuICAgVGhlcmVmb3JlLCBJIGNsYWltLCB0aGVyZSBpcyBubw0KCT4gd2F5IHRvIHBhc3MNCgk+ICAgICAgID4gPiBhIGRpYWwgc3RyaW5nDQoJPiAgICAgICA+DQoJPiAgICAgICA+IEJyaWFuLCAgV2hhdCBwYXJ0IG9mIGEgZGlhbCBzdHJpbmcgZG9lc24ndCBmaXQgaW50bzoNCgk+IDEqcGhvbmVkaWdpdCAgID8NCgk+ICAgICAgID4NCgk+ICAgICAgID4gcGhvbmVkaWdpdCA9ICIwIiAvICIxIiAvICIyIiAvICIzIiAvICI0IiAvICI1IiAvICI2IiAvICI3IiAvDQoJPiAgICAgICA+ICI4IiAvICI5IiAvDQoJPiAgICAgICA+ICAgICAgICAgICAgICAgIkEiIC8gIkIiIC8gIkMiIC8gIkQiIC8gIkUiIC8gIkYiDQoJPiAgICAgICA+DQoJPiAgICAgICA+IEUgY29ycmVzcG9uZHMgdG8gKiAgYW5kIEYgY29ycmVzcG9uZHMgdG8gIw0KCT4gICAgICAgPg0KCT4gICAgICAgPiB0aGFua3MsDQoJPiAgICAgICA+IC1yb2hhbg0KCT4gICAgICAgPg0KCT4gICAgICAgPg0KCT4gICAgICAgPiA+ICwgdW5sZXNzIHlvdSBwdXQgaXQgaW4gYSB1c2VybmFtZSBvbiBhIFNJUCB1cmksDQoJPiAgICAgICA+ID4gYW5kIGRlbm90ZSB0aGF0IGl0IGlzIGEgZGlhbCBzdHJpbmcsIGZvciB3aGljaCBhDQoJPiBwaG9uZSBudW1iZXIgaXMNCgk+ICAgICAgID4gPiBhIHByb3BlciBzdWJzZXQgZm9yIG1vc3QgZGlhbCBwbGFucywgYnkgc3BlY2lmeWluZw0KCT4gdXNlcj1waG9uZS4NCgk+ICAgICAgID4gPg0KCT4gICAgICAgPiA+IFBhdWwgZGlzYWdyZWVzLiAgSGUgdGhpbmtzIGhlIGNhbiBzZW5kIGEgZGlhbA0KCT4gc3RyaW5nIGluIGEgdGVsIHVyaS4NCgk+ICAgICAgID4gPiBXaXRob3V0IHNvbWUga2luZCBvZiByZXNvbHV0aW9uIG9mIHRoYXQgaXNzdWUsIHdlDQoJPiBoYXZlIGEgcHJvYmxlbS4NCgk+ICAgICAgID4gPg0KCT4gICAgICAgPiA+IEJyaWFuDQoJPiAgICAgICA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+ICAgICAgID4gPiBGcm9tOiBGcmFuY29pcyBBdWRldCBbbWFpbHRvOmF1ZGV0QG5vcnRlbG5ldHdvcmtzLmNvbV0NCgk+ICAgICAgID4gPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAxNSwgMjAwMyAxMjoxMCBQTQ0KCT4gICAgICAgPiA+IFRvOiAnUGF1bCBLeXppdmF0Jw0KCT4gICAgICAgPiA+IENjOiAnUm9zZW4sIEJyaWFuJzsgJ0JvYiBQZW5maWVsZCc7ICdzaXBAaWV0Zi5vcmcnDQoJPiAgICAgICA+ID4gU3ViamVjdDogUkU6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lDQoJPiAgICAgICA+ID4NCgk+ICAgICAgID4gPg0KCT4gICAgICAgPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4gICAgICAgPiA+PiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBjaXNjby5jb21dDQoJPiAgICAgICA+ID4+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDE1LCAyMDAzIDA2OjU4DQoJPiAgICAgICA+ID4+IFRvOiBBdWRldCwgRnJhbmNvaXMgW1NDMTAwOjRLMDI6RVhDSF0NCgk+ICAgICAgID4gPj4gQ2M6ICdSb3NlbiwgQnJpYW4nOyAnQm9iIFBlbmZpZWxkJzsgJ3NpcEBpZXRmLm9yZycNCgk+ICAgICAgID4gPj4gU3ViamVjdDogUmU6IFtTaXBdIFNJUElUIEludGVyb3AgcHJvYmxlbSB3aXRoIDt1c2VyPXBob25lDQoJPiAgICAgICA+ID4gWyBzdHVmZiBkZWxldGVkIGFzIGl0IGxvb2tzIGxpa2Ugd2UgYXJlIGluIGFncmVlbWVudCBdDQoJPiAgICAgICA+ID4+IEknbSBub3Qgc3VyZSBhYm91dCB0aGUgIm1vc3QiIHBhcnQuIFNvbWUgZG8sIHNvbWUNCgk+IGRvbid0LiBBcyBzcGVjIGlzDQoJPiAgICAgICA+ID4+IGN1cnJlbnRseSB3cml0dGVuLCB0aGUgZXF1aXZhbGVuY2UgYmV0d2VlbiB0ZWwgYW5kDQoJPiAgICAgICA+IHNpcC91c2VyPXBob25lIGlzDQoJPiAgICAgICA+ID4+IG9ubHkgb25lIHdheS4gKElGIHRoZSB1c2VycGFydCBjb21lcyBmcm9tIGEgdGVsLCB0aGVuIHRoZXJlDQoJPiAgICAgICA+ID4+IFNIT1VMRCBiZSBhDQoJPiAgICAgICA+ID4+IHVzZXI9cGhvbmUsIGJ1dCB0aGUgcHJlc2VuY2Ugb2YgdXNlcj1waG9uZSBkb2VzDQoJPiBub3QgaW1wbHkgdGhlDQoJPiAgICAgICA+ID4+IHVzZXJwYXJ0DQoJPiAgICAgICA+ID4+IGNvbmZvcm1zIHRvIHRlbC4pDQoJPiAgICAgICA+ID4+DQoJPiAgICAgICA+ID4+IEkgcGVyc29uYWxseSBhbSBoYXBweSB3aXRoIHRoZSBtb3JlIHN0cmljdA0KCT4gaW50ZXJwcmV0YXRpb24uIEJ1dCBJIGFtDQoJPiAgICAgICA+ID4+IHRyeWluZyB0byBob2xkIG91dCBhbiBvbGl2ZSBicmFuY2ggaW4gb3JkZXIgdG8NCgk+IHJlYWNoIGEgbGV2ZWwNCgk+ICAgICAgID4gPj4gb2YgYWdyZWVtZW50Lg0KCT4gICAgICAgPiA+IE9LLiBJdCBzZWVtcyB0aGF0IHdlIGFyZSBpbiBhZ3JlZW1lbnQuDQoJPiAgICAgICA+ID4gTXkgc3VnZ2VzdGlvbiBpcyB0byBhc2sgdGhlIHF1ZXN0aW9uIHRvIHRoZSBncm91cA0KCT4gb2YgaXMgYW55Ym9keQ0KCT4gICAgICAgPiA+IG9iamVjdHMgdG8gbWFrZSBpdCBleHBsaWNpdCB0aGF0IHVzZXI9cGhvbmVzIG1lYW5zIHRoYXQgdGhlDQoJPiAgICAgICA+IHNpcCBVUkkgaXMNCgk+ICAgICAgID4gPiBkZXJpdmVkDQoJPiAgICAgICA+ID4gZnJvbSBhIHRlbCBVUkk/DQoJPiAgICAgICA+ID4gSWYgdGhlIGFuc3dlciBpcyBubywgdGhlbiBJIHRoaW5rIHdlIGNhbiBwcm9iYWJseQ0KCT4gZmluYWxseSBwdXQgdGhpcw0KCT4gICAgICAgPiA+IGlzc3VlDQoJPiAgICAgICA+ID4gdG8gcmVzdC4gT3RoZXJ3aXNlLCB3ZSBuZWVkIHRvIHJld29yayB0aGUgd2hvbGUgdGhpbmcuLi4NCgk+ICAgICAgID4gPiBTby4uLiBEb2VzIGFueWJvZHkgc3Ryb25nbHkgb2JqZWN0IHRvIGV4cGxpY2l0bHkgbWFraW5nIHRoZQ0KCT4gICAgICAgPiB1c2VyPXBob25lDQoJPiAgICAgICA+ID4gYXR0dHJpYnV0ZSBtZWFuIHRoYXQgdGhlIFNJUCBVUkkgd2FzIGRlcml2ZWQgZnJvbSBhIHRlbCBVUkk/DQoJPiAgICAgICA+ID4+PiBBcHBseWluZyB0aGUgcnVsZXMgb2YgUkZDMzI2MS8xOS4xLjYgaW5zdGVhZCwgd2UnZCBnZXQ6DQoJPiAgICAgICA+ID4+Pg0KCT4gICAgICAgPiA+Pj4NCgk+ICAgICAgID4gPj4+DQoJPiBzaXA6MTIzNDtwaG9uZS1jb250ZXh0PXlvdXItZGlhbHBsYW4uZm9vLmJhckBmb28uYmFyO3VzZXI9cGhvbmUNCgk+ICAgICAgID4gPj4+DQoJPiAgICAgICA+ID4+PiBXaGljaCAobGlrZSB0aGUgdGVsIFVSSSkgc3BlY2lmaWNhbGx5IGlkZW50aWZpZXMgdGhlDQoJPiAgICAgICA+ID4+IGRpYWxpbmcgcGxhbiBhbmQNCgk+ICAgICAgID4gPj4+IGRvZXMgbm90IHJlcXVpcmUgb25lIEROUyBlbnRyeSBwZXIgZGlhbGxpbmcgcGxhbi4NCgk+ICAgICAgID4gPj4NCgk+ICAgICAgID4gPj4NCgk+ICAgICAgID4gPj4gSSBhZ3JlZSB0aGF0IHRoaXMgaXMgYWxzbyBhIGZpbmUgdXNhZ2UuDQoJPiAgICAgICA+ID4+DQoJPiAgICAgICA+ID4+IEJ1dCB3aGF0IGlzIGJlbmVmaXQgb2YgdGhpcyBvdmVyIHVzaW5nIHRoZSB0ZWwgZm9ybWF0IGFuZA0KCT4gICAgICAgPiA+PiB0aGVuIHBhc3NpbmcNCgk+ICAgICAgID4gPj4gdGhlIHJlcXVlc3QgdG8gc2lwOmZvby5iYXI/DQoJPiAgICAgICA+ID4gVGhlIHRlbCBVUkkgZm9ybWF0IGFzc3VtZXMgdGhhdCB0aGUgcHJveHkga25vd3Mgd2hpY2ggcHJveHkNCgk+ICAgICAgID4gaXMgYXdhcmUNCgk+ICAgICAgID4gPiBvZiB0aGUNCgk+ICAgICAgID4gPiBwaG9uZSBjb250ZXh0DQoJPiAgICAgICA+ID4gYW5kIHRlbCBVUklzIChpdCBjb3VsZCBiZSBpdHNlbGYsIG9yIGl0IGNvdWxkIGtub3cgd2hpY2gNCgk+ICAgICAgID4gcHJveHkgdG8gcm91dGUNCgk+ICAgICAgID4gPiBzZXNzaW9ucyB0bykuDQoJPiAgICAgICA+ID4gVGhlIHNpcCBVUkkgZm9ybWF0IGxldHMgeW91IHJvdXRlIGl0IHRvIGEgc3BlY2lmaWMgcHJveHkNCgk+ICAgICAgID4gdGhhdCBpcyBhd2FyZQ0KCT4gICAgICAgPiA+IG9mDQoJPiAgICAgICA+ID4gdGhlIHBob25lDQoJPiAgICAgICA+ID4gY29udGV4dCwgcG90ZW50aWFsbHkgd2l0aCAiZ2VuZXJpYyIgU0lQIHByb3hpZXMgaW4gYmV0d2Vlbg0KCT4gICAgICAgPiB0aGF0IGhhdmUNCgk+ICAgICAgID4gPiBubyBpZGVhDQoJPiAgICAgICA+ID4gaG93IHRvIHJvdXRlDQoJPiAgICAgICA+ID4gYmFzZWQgb24gcGhvbmUgY29udGV4dGVzIChvciBldmVuIHRlbCBVUklzKS4gVA0KCT4gICAgICAgPiA+DQoJPiAgICAgICA+ID4NCgk+ICAgICAgID4gPiBUaGV5IGJvdGggaGF2ZSBtZXJpdHMuDQoJPiAgICAgICA+ID4NCgk+ICAgICAgID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4gICAgICAgPiA+IFNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KCT4gICAgICAgPiA+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbA0KCT4gICAgICAgPiA+IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zDQoJPiBvbiBjdXJyZW50IHNpcA0KCT4gICAgICAgPiA+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZQ0KCT4gYXBwbGljYXRpb24gb2Ygc2lwDQoJPiAgICAgICA+DQoJPiAgICAgIA0KCT4gICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+ICAgICAgIFNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KCT4gICAgICAgVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQoJPiAgICAgICBVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbg0KCT4gY3VycmVudCBzaXANCgk+ICAgICAgIFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZQ0KCT4gYXBwbGljYXRpb24gb2Ygc2lwDQoJPiAgICAgIA0KCT4NCgk+DQoJDQoNCg==_______________________________________________Sip mailing list  https://www1.ietf.org/mailman/listinfo/sipThis list is for NEW development of the core SIP ProtocolUse [email-masked] for questions on current sipUse [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 19 Sep 2003 13:11:34 -0700

If the proxy knows that "phone-context=dial-digit-us.marconi.com" for
example
means a dial plan, then it would know it is a dial digit string (like
from a dumb phone). If instead it says "phone-context=global.marconi.com"
(for example), then it would know it is a Marconi private NUMBER (like from
a PBX gateway).

> Sent: Friday, September 19, 2003 13:02
> To: 'Stastny Richard'; Rohan Mahy
> Cc: Audet, Francois [SC100:4K02:EXCH]; Paul Kyzivat; Bob 
> Penfield; [email-masked]
> A user at a dumb phone always enters a dial string.
> No argument.
> 
> However, at some point, either a UA translates a dial string
> to a phone number, or a downstream proxy does it.  At that 
> point it isn't a dial string, it's a phone number, and it 
> might be in a context (it could be global).  What I've 
> mentioned is a case, which I think is pretty common, where 
> the number is not represented the same way as a dial string 
> and a phone number, and yet is in the same domain.
> 
> Let's take a practical example.  Suppose I have a domain with
> a reasonably smart proxy server and a mix of phones.  Some 
> phones have dialstring translation, some don't.  The proxy 
> server can translate dial strings to phone numbers, and it 
> also can route phone numbers.  Obviously it can do both (ie 
> translate then route).
> 
> Now, how does the proxy know if it needs to translate?  That 
> is, how does it know that a uri passed to it is a dial string 
> vs a phone number?  If I pass it a phone number and it 
> decides to apply it's dialstring processing, that will fail.  
> If I pass a 
> dial string and it just routes, that will fail.  It has to 
> know what it is given.  In my example it was 
> [email-masked] That's a phone number, and a dial 
> string, but it's two different destinations.  In my numbering 
> plan, it's my phone.  In my dialing plan it's an extension in 
> another office.
> 
> Brian
> 
> Brian
> 
> > Sent: Friday, September 19, 2003 3:33 PM
> > Brian,
> > If you pick up a phone and enter digits, it ALWAYS a dialing string 
> > and you are ALWAYS in ONE and ONLY ONE dialing plan..
> >  
> > You never enter a phone number directly, you always
> > dial (if you dial a local number, the mapping may be 1:1)
> >  
> > So if you enter a dial string in a SIP phone and iu sends
> > it with [email-masked] to your defaulr sip server, this 
> server then 
> > evaluates the dialing plan and translates it to a numbering plan.
> >  
> > Btw, thats exactly how fwd, iptel sipphone, ... are implemeted.
> >  
> > Richard
> > 
> > 	Gesendet: Fr 19.09.2003 19:37 
> > 	An: Stastny Richard; Rohan Mahy 
> > 	>       > > objects to make it explicit that 
> > user=phones means that the
> > 	>       > sip URI is
> > 	>       > > derived
> > 	>       > > from a tel URI?
> > 	>       > > So... Does anybody strongly object to 
> > explicitly making the
> > 	>       > user=phone
> > 	>       > > and tel URIs (it could be itself, or it 
> > could know which
> > 	>       > proxy to route
> > 	>       > > sessions to).
> > 	>       > > Sip mailing list  
> > https://www1.ietf.org/mailman/listinfo/sip
> > 	>       Sip mailing list  
> > https://www1.ietf.org/mailman/listinfo/sip

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Sep 2003 18:34:12 -0400

Stastny Richard wrote:
> santaclara.proxy.com and in the other case
> chicago.proxy.com if you just dial 3756?

A really dumb phone won't do both. You just configure it with the one 
string to append.

> access code to the default proxy and let it doing the work,

As Francois has said, you may not want to have a 1:1 correlation between 
dial plans and proxies. You may want every single user to have his own 
dialplan, which is evaluated by the proxy.

> or you use separate lines and swich between them.

Yes. A slightly smarter phone might have a separate context for each "line".

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 25 Sep 2003 10:04:11 -0700

I agree with Rohan.

> Sent: Thursday, September 25, 2003 07:31
> To: Rosen, Brian
> Cc: 'Stastny Richard'; Audet, Francois [SC100:4K02:EXCH]; 
> Paul Kyzivat; Bob Penfield; [email-masked]
> I expect that your address should be more like this:
> 
> sip:[email-masked]
> sip:[email-masked]
> tel:6826;phone-context=pit.marconi.com
> tel:7246826;phone-context=marconi.com
> tel:7246826;phone-context=+1222
> tel:+12227246826
> 
> which would make the dial string for the extension in the 
> other office  
> simply:
> 
> tel:7246826;phone-context=pit.marconi.com
> 
> but since you haven't given me much more to go on, I will assume two  
> different contexts.  One for the numbers you dial on your phone, and  
> another for your internal representation of a "phone number"  
> whatever  
> that is.
> 
> someone could express your phone number as: 
> tel:7248626;phone-context=pit.marconi.com
> 
> which then gets converted to: 
> sip:7248626;phone-context=[email-masked];user=phone
> 
> where a marconi.com proxy retargets to one of your AORs: 
> sip:[email-masked]
> 
> 
> when you dial a particular a dial string:
> sip:7248626;phone-context=pit-dial- 
> [email-masked];user=phone
> 
> the marconi.com proxy can apply the pittsburgh dial plan and 
> generate  
> whatever target it is supposed to generate.  maybe: 
> sip:[email-masked]  or tel:+442081118626, or whatever it means.
> 
> thanks,
> -rohan