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

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Sep 2003 10:24:45 -0400

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