Subject: RE: [SIP] Forcing call setup through home proxy (solution?)

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 19 May 2000 08:11:04 -0500

Can't the Request-URI be used to achieve this functionality? 

UA Oriented:

	I.e. the SIP message's IP destination could be the serving proxy in
the visited network and the Request-URI could indicate the home proxy. This
would allow the UA to be in control over whether the home proxy was in the
loop. See section 6.33.4 in
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-2543bis-00.pdf. [
Page 51 ]

Script or Network Oriented:

	An network oriented alternative would be to have scripts, profile or
triggers loaded on the serving proxy to rewrite or include the Request-URI
indicating involvement of the home server. This may or may not run into the
"gag me with a spoon" issue that Mike alluded to depending on where the
script came from.

Really Crapy Solution:

	Yet another network oriented method would be to simply have the
service logic on the serving proxy simply proxy the message to the address
of the home proxy; however, this would only work if no other proxies are
needed to be in the loop between the serving and home proxies- don't
recommend. This last one is a bad solution that I personally believe
violates the principles of SIP. It's a hack.

I believe all of these methods except the last would allow a per-message
selection of home proxy involvement, be legal in SIP and not go against the
design principles of the architecture. 

Are there any issues with the SIP violations that anyone is aware of for the
first two methods above?

> -----Original Message-----
> From:	Adam B. Roach [SMTP:[email-masked]]
> Sent:	Friday, May 19, 2000 5:49 AM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]; [email-masked]
> Subject:	Re: [SIP] Forcing call setup through home proxy (solution?)
> 
> >As I said before, some services to set up a call might depend on =
> >information
> >that only is available in the callers home network, and for security or
> >policy reasons might be impossible to access from other networks. In =
> >this
> >case MUST the call setup signaling go through the home network.
> >
> >I belive that this could be solved by adding a route header field =
> >containing
> >the address of the home server in the Invite message. If you follow the =
> >spec
> >must the first proxy in the visited network route the Invite to the =
> >home
> >proxy. This method allows for optimizing call setup when there is no =
> >service
> >that requires routing through the home network, and a method to =
> >indicate
> >when so should be the case.
> 
> At the third bakeoff, I went around to a number of people and
> asked how their proxies would behave if my client did this sort of
> thing. I got a variety of mixed answers, none of which were
> very encouraging. Some people wouldn't process it, for example,
> unless it had a To: tag (since routes can't appear on leg
> setup messages, or so goes the thinking). Most would completely
> forgo their internal logic and blindly forward the message
> (thus making their purpose only to add to the number of hops
> in the call signalling route).
> 
> I've been mulling this problem since. I don't think there's
> really a good solution; however, I want to run something by
> the group.
> 
> Back in the day, you could manually route e-mail messages through
> a variety of servers by specifying an email address of the format
> [email-masked]. Upon receiving this,
> ericsson.com would turn the last % into an @ and continue
> routing the message. This could be indefinitely chained
> to produce something like [email-masked]
> which would route the message through ericsson.com, then host1,
> then host2, and finally deliver it to host3.
> 
> So, what if we specified a fairly simple username convention
> stating that proxies MAY do something similar; for example,
> you could send something like:
> 
> INVITE sip:[email-masked] SIP/2.0
> 
> ...to the machine "localservices.mycompany.com". When the
> machine "firewall.mycompany.com" received the message, based on
> the presence of an escaped @ sign in the user field, he would
> strip the machine name in the request URI, expand the rightmost
> escaped @, and use that for his new request URI:
> 
> INVITE sip:[email-masked] SIP/2.0
> 
> Questions? Comments? Is there enough interest in this to
> warrant putting together a formal document?
> 
> -- 
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
> L-04
> [email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081
> USA
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip