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

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

> -----Original Message-----
> From: ext Rohan Mahy [mailto:[email-masked]]
> 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]
> Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> 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.

/Hisham

> 
> thanks,
> -rohan
> 
> > /Hisham
> >
> >
> >> -----Original Message-----
> >> From: ext Rohan Mahy [mailto:[email-masked]]
> >> Sent: Tuesday, September 16, 2003 7:27 PM
> >> To: Robert Sparks
> >> Cc: Paul Kyzivat; Adam Roach; 'Rosen, Brian'; [email-masked]
> >> Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone
> >>
> >>
> >>
> >> 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
> >>
> >>
> >> _______________________________________________
> >> 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: Robert Sparks <[email-masked]>
Date: Thu, 18 Sep 2003 09:25:42 -0500

.
On Thu, 2003-09-18 at 01:38, [email-masked] wrote:
<snip>
> 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.
<snip>
> > >> 	Route: <sip:transcoders.com;lr>, <sip:mci.com;lr>
<snip>
> > >> 	Route: <sip:transcoders.com;lr>

You missed the important part of what Rohan was trying to say I think

You are right that transcoders.com could cause either request
to go anywhere it wants. Suppose it sends the requests to att.com.

In case B, att.com could (and most likely would) legitimately 
believe it is responsible for figuring out what to do with 
tel: URIs - nothing malicious - its just normal processing.
Suppose it retargets it to one of its gateways. The request would 
then follow the route, where MCI proxy will forward the request 
back to the ATT gateway (until MCI gets wise and starts rejecting
such requests).

In case C, att.com has no legitimate claim on the RURI. It would be
constrained to send the message to MCI with its RURI unchanged.

So C does have significantly better properties than B.

RjS

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 18 Sep 2003 09:04:52 -0700 (PDT)

> 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