[SIPForum-techwg] Interoperability Draft v3 - scope and conformance

[Chris Sibley]

Paul,

Your points are very well taken. 

Our specification, as currently written, does call for the host portion
of the URI to be rewritten (to the peer's domain) before any SIP
messages cross the SP / Enterprise network boundaries (see section 11).
This should satisfy the requirements you outlined below regarding
routing and URI presentation (at least in the basic cases.)

That said, I think it is safe to say that the group is leaning toward at
least SUPPORTING tel: URIs between Enterprise and SP (I would certainly
be in favor of it). However, I would also wager a guess that the
majority of the group would not want tel: URIs to be the *ONLY* URI
scheme that can be used (i.e. SIP URIs are also valid). 

Question to the group: Could this issue be addressed by adding a third
option to sections 11.1.1 and 11.1.2 which utilizes tel: URIs in the
Request URI and TO: fields? If the answer is yes, would this be the
PREFERRED method?

Thanks,

--Chris


> 

**********************************************************************
This email may contain confidential information. If you are not
the intended recipient, please advise by return email and delete
immediately without reading or forwarding to others.
 - Cbeyond 
**********************************************************************-----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Monday, January 09, 2006 2:27 PM
> To: Chris Sibley
> Cc: Horvath Ernst; Elwell, John; Alan Johnston; SIP Forum Tech WG
> Subject: Re: [SIPForum-techwg] Interoperability Draft v3 - scope and
> conformance
> 
> 
> 
> Chris Sibley wrote:
> 
> > 3) The tel: URI
> >
> > [CS] RFC 3261 (section 19.1.6) already covers the conversion of tel:
> > URIs to SIP URIs. I really don't see any value in mandating "native"
> > support of tel: URIs on the SAS or PBX / IP phones. What am I
missing?
> 
> There are two interesting issues:
> 
> - routing
> - presentation of URIs
> 
> Routing:
> 
> A tel uri has a universal meaning. Each node that processes it may
> decide how to reach the target. Each may decide to go to the PSTN, and
> may use whatever pstn gw it wishes to do so.
> 
> A sip uri with user=phone may contain the a tel uri, but only nodes
that
> are part of the domain of the uri are allowed to take the phone number
> part into consideration for routing. Others must route to the
specified
> domain. So breakout to the pstn can only be done by the specified
domain.
> 
> This need not be a problem as long as the domain portion of the URI is
> rewritten when crossing domain boundaries, but it is at least a
concern.
> 
> Presentation of URIs:
> 
> I haven't been paying attention, but I am sure you have some rule for
> deciding what header will convey "callerid" information. Perhaps it is
> From, or P-Asserted-Identity, but it doesn't matter too much. In any
> case, if it contains a tel uri, then you can safely assume it is a
phone
> number and display it that way on callerid displays that want a number
> rather than a URI.
> 
> But suppose you get a sip uri as your callerid. How will that be
> displayed? By similar logic to that for routing, a recipient should
not
> display this as a phone number unless it is certain that is what it
is.
> That means the domain is *its* domain. If the domain is something
else,
> then it should not be interpretting the user part of the uri, or
> implying that the source of the call may be reached via the PSTN,
which
> is what displaying a phone number means. So you can find yourself in a
> situation where you either must "cheat" and interpret numbers that
> should not be interpretted, or else you must display a sip URI on a
> device that may not be able to do that well, or at all.
> 
> You avoid the problems by having the caller identified by a tel uri,
or
> by ensuring that the URI is rewritten with a suitable domain every
time
> the request crosses a domain boundary.
> 
> 	Paul