Subject: RE: [SIP] Possible REFER problem?

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 5 Sep 2000 12:39:04 -0400

I think the problem you identify is more general than call transfer.  It
applies whenever it is essential to reach the same UA as a previous call or
call leg.  The Contact: header is probably the necessary solution --
mimicing an existing call-leg is likely to have undesirable side-effects.

> -----Original Message-----
> From: Eric Tremblay [mailto:[email-masked]]
> Sent: Monday, September 04, 2000 8:24 PM
> To: Robert Sparks (E-mail)
> Cc: [email-masked]
> Subject: [SIP] Possible REFER problem?
> 
> 
> Hi,
> 
> I think I see a possible problem with the REFER request in 
> the context of a
> call transfer with consultation:
> 
> Suppose that Transferor and Transferee are connected.  Transferor puts
> Transferee on hold and calls Transfer Target (TT).  After the 
> brief call
> between Transferor and TT, Transferor sends a REFER request 
> to Transferee:
> 
> Transferor has 2 choices for the URL to put into the Refer-To 
> header of the
> REFER request.  It can either use the contact it has received 
> in the 200
> response of the call with TT or it can use the original URL 
> it has used to
> establish the call to TT (which usually points to a proxy or redirect
> server).
> 
> I think that using the contact URL in the Refer-To is not the 
> best thing to
> do because this could bypass some of the system policies that 
> requires all
> calls to go trough a proxy (for tracing, billing or whatever 
> services).
> Note that this is fixed by having TT return a 305 response to 
> the INVITE
> received from Transferee, in which case Transferee should 
> resend the INVITE
> to a proxy. 
> 
> On the other hand, when using the original URL in the 
> Refer-To, I think it
> is possible that the call from Transferee to TT will be 
> routed to a totaly
> different destination, probably because the proxy has forked 
> and someone
> else has answered before TT could. 
> 
> 
> I think the problem is as follows:
> 
> How can we make sure that the INVITE from Transferee to TT 
> will be answered
> by the same UA as the INVITE from Transferor to TT?  I think 
> that we want to
> allow some mobility to TT, but I also think that we would 
> like to reach the
> exact same UA as the call between Transferor and TT.
> 
> There is probably a way around this by having the Tranferor 
> keep the call up
> with TT (holding instead of terminating the call) AND making 
> Transferee send
> an INVITE to the proxy with the same Call-Id, From and To 
> (along with tags).
> The proxy would be tricked to think that this is a re-invite for the
> existing session between Transferor and TT and thus route it 
> to only TT.
> Not necessarly the nicest solution.
> 
> First, is this really a problem or I'm forgetting something?
> 
> Regards,
> 
> EricT
> 
> __________________________________________
> Eric Tremblay      | Mediatrix Telecom Inc.
> Technical Leader   | www.mediatrix.com
> 
> [email-masked]
> tel: +1-819-829-8749 x238
> fax: +1-819-829-5100
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
>

---

From: [email-masked]
Date: Tue, 5 Sep 2000 13:58:29 -0500

Jonathan Rosenberg wrote
> [email-masked] wrote:
> > 
> > Jonathan Rosenberg wrote
> > > No. It would not be routed to a "totally" different location.
> > > Forking in
> > > SIP is not meant to be a randomization process; its meant to
> > > be a means
> > > of finding the user where they are currently available. In a
> > > reasonable
> > > SIP system, if they are available at some destination for a
> > > first call,
> > > a second call should be able to "ring" that same phone as well.
> > >
> > 
> > How can extension groups be handled in SIP? For example, if 
> the URL is
> > sip:[email-masked], and five phones are supposed to ring at 
> once for five
> > different sales people (a ring-all extension group), or one 
> of five phones
> > is supposed to ring, selected in circular fashion (a 
> circular extension
> > group).
> 
> However you like it. Either approach is supported. Its a 
> matter of local
> policy in the proxy that servers acme.com.
> 

But doesn't this contradict your previous statement? With either type of
extension group, the REFER problem described in the original message of this
thread will arise, will it not? And with a circular extension group, a
subsequent request could be routed to "a totally different location", and
SIP would be acting as a sort of "randomization process".

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 5 Sep 2000 15:11:03 -0400

I see use of Contact: to select the exact destination as the equivalent of
"Call operator 58" back when operators routed most calls.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2000 2:58 PM
> To: [email-masked]
> Subject: RE: [SIP] Possible REFER problem?
> 
> 
> Jonathan Rosenberg wrote

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Sep 2000 02:53:15 -0400

Rohan Mahy wrote:
> > > There is probably a way around this by having the 
> Tranferor keep the 
> > call up
> > > with TT (holding instead of terminating the call) AND 
> making Transferee 
> > send
> (along with 
> > tags).
> > > existing session between Transferor and TT and thus route 
> it to only TT.
> >This won't help, since routing isn't going to be based on 
> Call-ID, To,
> >and From (tags or not). You would effectively have to force 
> a route, but
> >you cannot do so since you don't know a reasonable route from the
> >transferee to the TT.
> 
> Why does it need to take *exactly* the same route?
> 

It doesn't. You are missing my point. Proxies don't know about re-invites.
They don't route based on tags. The "faked" invite will have no route
headers, and thus will be routed as a brand new INVITE and be routed with
the same non-determinism as a normal INVITE to the transfer target.

> SIP would be acting as a sort of "randomization process".

Fair enough. I had forgotten about this case in my original note.

Cliff later writes:
> Another solution would be to use the To tag. Why not have the
> REFER-triggered INVITE include the To tag of the desired UAS 
> (but a brand
> new call ID)? If the INVITE gets rejected because of the To 
> tag, an INVITE
> without a To tag could then be sent, and nothing is lost. If 
> a UA that is
> not the intended Transfer Target rejects the INVITE because 
> it contains the
> wrong tag, then a benefit is realized.

This won't work with tag as currently defined. It has no significance
across call legs. Since the new INVITE has a different call ID (and
certainly a different From), it is a different call leg.

I had actually forgotten that we have alraedy defined a mechanism to
accomplish exactly what is desired here! Its the caller preferences
extension. It allows you to specify a specific contact you'd like to reach.

So, lets say A is talking to B. A then calls C, and wants to transfer B to
C. The REFER from A to B would look like:

REFER sip:B
From: sip:A
Refer-To: sip:C?Accept-Contact=sip:C.contact-address

This has the nice property that the request URI of the INVITE generated by B
will still be C's regular SIP address, allowing it to be routed properly.
The Accept-Contact will help ensure that a proxy only sends it to a specific
instance.

This is worth noting in the REFER document.

-Jonathan R.