Subject: RE: [SIP] Possible REFER problem?

From: Eric Tremblay <[email-masked]>
Date: Wed, 25 Oct 2000 09:04:30 -0400

Hi Jonathan and Cliff,

I'm reviving and old thread ;)

If you remember, the problem was when doing call transfer with consultation
with the REFER request, how can we make sure that the INVITE request (from
the Transferee to the Transfer Target) is going to reach the exact same
User-Agent as the one that was consulted by the Transferor.  

The solution was to use the header "Accept-Contact" and specify the contact
of the transfer target.

I was taking a look at the caller preferences extension, thinking that
"Accept-Contact" had solved our problem, but I think it does not solves the
problem.

Suppose we have the following participants:

Transferor (Tror)
- Sip address: sip:[email-masked]
- Current location: sip:[email-masked]

Transferee (Tree)
- Sip address: sip:[email-masked]
- Current location: sip:[email-masked]
 
Transfer-Target (TT)
- Sip address: sip:[email-masked]
- Current location: sip:[email-masked]

Tror and Tree have established calls.  Tror contacts TT and ask if he wishes
to accept the call, which he does.  Tror sends the following REFER to Tree:

REFER sip:[email-masked] SIP/2.0
From: sip:[email-masked]
To: sip:[email-masked]
Refer-To: sip:[email-masked]?Accept-Contact=sip:[email-masked]
...

Which spawns the INVITE from Tree to a proxy server somewhere in ACME.

INVITE sip:[email-masked] SIP/2.0
From: sip:[email-masked]
To: sip:[email-masked]
Accept-Contact=sip:[email-masked]
Referred-By: ...
...

The proxy receives this request and checks with the location server to find
where can [email-masked] be found.  The list of contact returned could look
like the following:

Contact: sip:[email-masked]
Contact: sip:[email-masked]
Contact: sip:[email-masked]

Now the proxy has these 3 contacts that do not match the Accept-Contact URL,
although the proxy at mediatrix.com would translate [email-masked] to
[email-masked].  Now the proxy does not really know which contact
is prefeered, and can try any of the three contacts, and someone can happily
answer at those addresses.

How can we avoid this?

First, I think that the Proxy should send the Accept-Contact in its
downstream requests, in order to have the downstream proxies be able to use
the same mechanism.  But in truth, the proxy does not know if the downstream
request is going to be sent to a proxy or to a UA, so it is possible for a
UA to receive such a request.  Would it be a good idea to have the UA take a
look at the Accept-Contact header to know if the request is really for him?
I think that the current caller preferences draft states that a UA should
ignore these header if it receives it.

Best regards,

EricT

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Sunday, September 10, 2000 2:53 AM
> To: [email-masked]'; [email-masked]'
> Cc: [email-masked]'
> Subject: RE: [SIP] Possible REFER problem?
> 
> 
> 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
> > > > 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.
> > >
> > >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.
> 
> Cliff later writes:
> > > > 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".
> 
> 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.
> 

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