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

From: [email-masked]
Date: Thu, 4 Sep 2003 15:26:18 +0300

> -----Original Message-----
> From: ext Stastny Richard [mailto:[email-masked]]
> Sent: Thursday, September 04, 2003 3:15 PM
> To: Khartabil Hisham (NMP/Helsinki); [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> > 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)

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

> 
> 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
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] 
> > Sent: Thursday, September 04, 2003 1:52 PM
> > To: Stastny Richard; [email-masked]; 
> > [email-masked]; [email-masked]
> > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> > 
> > > -----Original Message-----
> > > From: ext Stastny Richard [mailto:[email-masked]]
> > > Sent: Thursday, September 04, 2003 2:13 PM
> > > To: Christer Holmberg (JO/LMF); Bob Penfield; [email-masked]
> > > Subject: RE: [Sip] SIPIT Interop problem with ;user=phone
> > > 
> > > 
> > > 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.
> > 
> > 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
> > 
> > > 
> > > 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
> > > 
> > > 
> > > > -----Original Message-----
> > > > 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
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > 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]
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > 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
> > > 
> > 
> 

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Fri, 05 Sep 2003 12:13:00 -0500

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

Well, I think we know how to tell [email-masked] from 
[email-masked], with or without user=phone.

There's certainly no particular reason that the operator1.com proxy 
should know to forward [email-masked];user=phone to 
[email-masked], One COULD manually configure that sort of rule, but 
it seems likely to break the universe if you tried to do it for ever 
possible phone number.

You're asking "If @operator1.com is the default domain, how do I dial 
something @operator2.com"? The answer is -- the user has to enter that 
part, somehow. If your email client adds @nokia.com to outgoing email 
that doesn't specify a domain, and you send an email to "dean.willis", I 
imagine that the nokia email sever is likely to reject it -- unless 
they've decided to offer me enough money to defect and I haven't found 
out yet (I'm easy, but not cheap).

What I think you WANT to be asking is "How does a user entering a 
short-form request indicate whether he wants it treated as a phone 
number (looked up in ENUM or sent to a PSTN gateway) or treated as a SIP 
username?"

I don't have an answer for that. None of the phones I use seem to have a 
mechanism for entering this distinction.

--
Dean

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 12 Sep 2003 10:31:08 -0700

On Friday, September 5, 2003, at 10:13 AM, Dean Willis wrote:
>> 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.
>>
>
> [email-masked], One COULD manually configure that sort of rule,  
> but it seems likely to break the universe if you tried to do it for  
> ever possible phone number.
>
> that doesn't specify a domain, and you send an email to "dean.willis",  
> I imagine that the nokia email sever is likely to reject it -- unless  
> number (looked up in ENUM or sent to a PSTN gateway) or treated as a  
> SIP username?"
>
> I don't have an answer for that. None of the phones I use seem to have  
> a mechanism for entering this distinction.

One mechanism would be to use a list of regular expressions, or more  
specifically, a locally-configured dialplan of some sort.  Many IP  
phone vendors have this feature.  For example (as an existence proof  
only):

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/ 
ipp7960/addprot/sip/admin/ver5_1/sipins44.htm#1047995

I would have included references to other vendors as well, but I am on  
an airplane now....

thanks,
-rohan