Subject: RE: [SIP] Possible REFER problem?

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 23 Nov 2000 22:36:47 -0500

Sorry for the delay in picking this thread up... I'm trying to finish a rev
on Caller Prefs, and there are some issues here.

First off, Eric raised a problem with my proposed solution. I'm replicating
it here since its been a while:

> 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.

Eric is correct that even if none of the registered contacts matches those
in the Accept-Contact header, a proxy will forward the request, with
Accept-Contact intact. As a result, the request may ultimately arrive at
several UAs that don't match. Another related problem is that Accept-Contact
is not specified as a filter-all-but rule (partly for the reasons Eric
observes; a request would never get past the first proxy since the Contact
might be known only at a later proxy). The caller preferences specification
has a process for combining the q values. At best, it would effect ordering
of a sequential search. 

What we need here is a mechanism that says, "I only want to talk to you if
you are one of these Contacts". This rule can ONLY be enforced in the UAs.
This capability does not exist in the current caller preferences draft.
However, I think it will prove useful here (actually, it really is needed
for call transfer, more on that below), and other places too. So, I will add
an Accept-Only-Contact header to caller preferences, with this header only
being used by a UA.

Now, on to some other issues. Consider the scenario of A talking to B. A
calls C, and then A  wishes to transfer B to C, making sure that B gets the
same instance of C that A was talking to. Adam asked, why not have A refer B
to the Contact obtained from C:

> At the risk of sounding daft, I don't see why using the "Contact:"
> header as the new "INVITE" URI is considered Evil in this case.
> 
> When explaining the difference between, say, the "From:" (or "To:")
> field and the "Contact:" field, I generally think of "From:"/"To:" as
> being the persistent URI for contacting the appropriate resource in 
> an abstract sense (by resource, I mean "Adam Roach" or 
> "helpdesk staffer" 
> or "sales representative"), while the "Contact:" URI 
> indicates "where to
> get to me (as a particular instance of that resource) on this 
> particular
> device at this particular moment."

The answer is that URIs most definitely have a context; a place from which
they can be usefully used. In a perfect world with no NATs, firewalls, or
devices that want to know whats going on within the network, it would work
dandy. But thats not reality. The classic example is an ACD application,
where [email-masked] can be routed to a variety of agents
([email-masked]). Sophisticated software tracks the call status
of the various agents, how much volume they get, etc. Incoming calls MUST
come in through this helpdesk proxy to work. The proxy always record routes.
In fact, to enforce this, the proxy has access to a hosts file with the
host32.helpdesk.com address mapped to an IP address. Outside of this proxy,
that hostname is unroutable. So, if A called B, and then A called C, and C
was one of these operators, the URI returned by C
([email-masked]) will definitely not be useful for B to use
directly.

Another issue was raised about the possibility of per-call Contacts
generated dynamically by a UA. Yikes. I don't know any UA that does this.
Unfortunately, if a UA provides no consistent form of identification to the
network or other users, it can't expect to be consistently transferred to in
this case. So, I think we can punt this case and declare it as "don't do
this".

Robert had proposed a hybrid approach:
> Given all that, and the likelyhood that for many (if not
> most) instances, the contact provided in the Contact URL
> _is_ routable, what problems exist with taking the following
> approach?
> 
>   1) REFER B directly to the contact that C provided to A.
>   2) If it fails, REFER B to C's well known URL with an Accept-Contact
>      header containing the contact that C provided to A.
> 

Hmm. Turns out you can construct cases where neither (1) nor (2) will work.

What if, when A called C, it wasn't really C that was called, but some
time-of-day routed 800 number that got forwarded to C. Now, while A talks to
C, the logic for the forwarding changes. Now, when A sends a REFER to B, the
URI in the Refer-To is that 800 number. It never even comes close to being
sent to a single UA that matches the Accept-Contact header. In this
scenario, sending directly to the Contact won't work either, since the
operator is not directly callable. Don't you love feature interaction
problems ;) ?

So, basically, referring to exactly the same person I'm talking to is hard
because (1) their unique address may not be directly routable, and (2) the
logic used to get to that person from a directly routable address may
change. If you ignore (1), you come up with the solution to (2) of sending
to the Contact. If you ignore (2), you come up with the Accept-Only-Contact
solution to deal with (1). If you want to deal with both (1) and (2), its
really rough. I thought about having A also include Route headers as header
params to the URI in the Refer-To, but this doesn't work either. A route
header set usable from A may not be usable from B, for many reasons, not the
least of which is problem (1) once more.

Perhaps these cases are so extreme its not worth worrying about. I wouldn't
be surprised if they don't work in the PSTN either. 

So, despite its complexity, I feel compelled to recommend that Robert's
hybrid approach be described in the REFER specification as the preferred way
to do transfer out of consultation, along with a nice long explanation of
why it needs to be so. I'm not sure about the order though. I suspect that
(2) will work in far more cases than (1) will. I welcome better ideas if
anyone has any...

Thanks,
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: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Fri, 24 Nov 2000 12:13:29 +0530

My two cents of thoughts on this one... I don't know how feasible my
suggestion below is. The crux of this problem in my opinion here arises out
of the fact that the Transferor is first initiating an INVITE to check the
availability of the transfer target and depending upon the type of transfer,
the TT (or the transferree) initiates an INVITE to the transferree(or TT)
based either upon the request URL / contact URL received. This problem could
be solved if the transferee invoked the INVITE in all cases.
Venkatesh
----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "'Billy Biggs'" <[email-masked]>; "Robert Sparks"
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 24, 2000 9:06 AM
Subject: RE: [SIP] Possible REFER problem?

---

From: Billy Biggs <[email-masked]>
Date: Tue, 28 Nov 2000 10:31:40 -0600

Our situation is as follows:

             A
            / \
           B   C

  A is in a 3-way call with B and C and wishes to be excused.  If C
called A, then A has no 'well-known URI' for C.  The best address is the
Contact.  The From is not useful because it may be an unknown URI
scheme, or C might be a 3pcc server, or the URI may be stale (or
fork)...

  In our implementation, we use the Contact exclusively.  I expect other
implementations will also generalize transfer with consultation by
instead implementing call handoff, and act similarily.  If we REFER B to
C and it fails, maybe we'll instead REFER C to B.  If some server really
needs to be in the signalling path, it should do 3pcc, or mangle the
Contact, or act as a transparent SIP proxy...

  Jonathan discussed why using the Contact is dangerous:

> The answer is that URIs most definitely have a context; a place from
> which they can be usefully used. In a perfect world with no NATs,
> firewalls, or devices that want to know whats going on within the
> network, it would work dandy. But thats not reality. The classic
> example is an ACD application, where [email-masked] can be routed
> to a variety of agents ([email-masked]). Sophisticated
> software tracks the call status of the various agents, how much volume
> they get, etc. Incoming calls MUST come in through this helpdesk proxy
> to work. The proxy always record routes.  In fact, to enforce this,
> the proxy has access to a hosts file with the host32.helpdesk.com
> address mapped to an IP address. Outside of this proxy, that hostname
> is unroutable. So, if A called B, and then A called C, and C was one
> of these operators, the URI returned by C
> ([email-masked]) will definitely not be useful for B to
> use directly.

  With an ACD application, in order to enforce all calls through the
server, the server must perform 3pcc and only SIPly expose itself, or
have all of the clients collude with the server and redirect all
incoming direct-dialed calls.  I don't think a Record-Route'ing proxy
with some unroutable client addresses is clean, and I think it is
reasonable to have attended transfer fail in these scenarios.

  If the Contact address is not generally routable (firewalls and NATs),
then it should be mangled if the user wishes attended transfer to work,
or have calls go through some helper 3pcc box.  I see this as the only
reasonable solution.

> Perhaps these cases are so extreme its not worth worrying about. I
> wouldn't be surprised if they don't work in the PSTN either. 

  The PSTN has no concept of a REFER, which is where all this breaks
down.  Again, the 3-way call:

             A
            / \
           B   C

  A cannot excuse itself from the call in the PSTN.  It can only keep
the bridge active.  This is acceptable because A is a PBX or similar
server.  There is no concept of signalling a transfer over the PSTN
where the transferred party makes a new call.

> So, despite its complexity, I feel compelled to recommend that
> Robert's hybrid approach be described in the REFER specification as
> the preferred way to do transfer out of consultation, along with a
> nice long explanation of why it needs to be so. I'm not sure about the
> order though. I suspect that (2) will work in far more cases than (1)
> will. I welcome better ideas if anyone has any...

  It might be better to remove transfer out of consultation from the
REFER draft, and maybe do a new draft on attended transfer, discussing
these options and also introducing the replaces header from
draft-biggs-sip-replaces-00.

  I really want to be able to have A silently excuse itself from the
conference.  This will help with many services, including moving
transparently to a conference bridge, call park with server, ...

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]