Subject: RE: [SIP] Possible REFER problem?

From: [email-masked]
Date: Thu, 7 Sep 2000 09:11:42 -0500

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.

Although it is not the intention of To tags that they be included in INVITEs
to new sessions, UAS's currently may allow new INVITEs with To tags as a
means of working around a crash. So why not take advantage of that to make
REFERs more robust (and maybe add a couple of SHOULDs to the RFC)?.

> -----Original Message-----
> From: EXT 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
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 7 Sep 2000 12:17:45 -0400

Using the To tag would work but
opens/maintains a pin-hole in the proxies
for most anyone to suddenly reach a specific
user behind a proxy (or B2BUA).  I'd rather see
something like a "PENDING-INVITE" method
be used to temporarily open the pin-hole with
needed approval by the Referred-To user agent.

The "PENDING-INVITE" was briefly mentioned
in the "draft-ietf-sip-cc-transfer-00 comments
and questions" thread.  In addition to ensuring
anonymity behind a proxy (or B2BUA) and the
correct party being reached, it would also
identify how the REFERring party was hoping
the resulting INVITE would be treated in relation
to the other corresponding call-leg (switch-bye,
mixed, reject, hold-me, ...).