Subject: [SIP] Possible REFER problem?

From: Eric Tremblay <[email-masked]>
Date: Mon, 4 Sep 2000 20:23:37 -0400

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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 04 Sep 2000 22:58:48 -0400

> received from Transferee, in which case Transferee should resend the INVITE

Correct. It should not use the Contact URL.

> else has answered before TT could.

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. 

> Not necessarly the nicest solution.

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. 

> First, is this really a problem or I'm forgetting something?

I do not believe it is a real problem.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 05 Sep 2000 08:40:43 -0700

>Correct. It should not use the Contact URL.

What is the problem with issuing disambiguous requests?  We can still send 
them through a proxy.

A called B
B put A on hold
B called C
B completes the transfer by sending this REFER

REFER sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP userB-deskphone.widgets.com:5060
To: <sip:[email-masked]>
From: <sip:[email-masked]>
Call-Id: [email-masked]     (same ID used for A's INVITE to B)
Refer-To: <sip:[email-masked]
  ?To=<sip:[email-masked]>&Call-Id=[email-masked]>
Referred-By: <sip:[email-masked]> <sip:[email-masked]
  ?To=<sip:[email-masked]>&Call-Id=[email-masked]>

A generates this INVITE from the REFER

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP 171.69.34.14:5060
To: <sip:[email-masked]>
From: <sip:[email-masked]>
Call-ID: [email-masked]
Referred-By: <sip:[email-masked]> <sip:[email-masked]
  ?To=<sip:[email-masked]>&Call-Id=[email-masked]>
Contact: <sip:[email-masked]>

There is no reason that these two requests can't make it through the 
desired chain of proxies.  The administrators of loopback.edu and 
widgets.com will probably both setup policies/firewalls/whatever to insure 
that, whether the requests are first-time INVITEs, reINVITEs, reffered 
INVITEs, or other methods.

>a second call should be able to "ring" that same phone as well.

I disagree.  CPL or other routing logic may very reasonably direct caller A 
to Voicemail, while it directs caller B directly to a cell phone or 
conference room.  Just because I REGISTER from a conference room, doesn't 
mean I want ALL my calls to come there.

>you cannot do so since you don't know a reasonable route from the

Why does it need to take *exactly* the same route?

thanks,
-rohan