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

From: [email-masked]
Date: Thu, 4 Sep 2003 14:52:17 +0300

> -----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: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Thu, 4 Sep 2003 13:16:29 +0100

At 2:52 pm +0300 4/9/03, [email-masked] wrote:
<Snip from Richard>
>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]

Hi Folks,
   I am losing the plot here.
At what point did someone seriously suggest that sip:[email-masked]
is different from sip:[email-masked]? I've seen these comments but
assumed that they were typos. Apparently not.

If two URIs match according to the rules in 3261 then they're the same.
Thus if my phone constructs an INVITE with 'sip:[email-masked]' as the
To: field (whilst I typed in the digits '12345'), this is NO different
from me entering [email-masked]' onto the phone and it constructing an
INVITE with 'sip:[email-masked]' as the To: field. The recipient of this
INVITE will (normally) process the two as the same.

If your proxy wants to use some other magic to differentiate between this
destination, that's an internal issue for the Proxy and not a protocol issue.

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