Subject: Re: [SIP] Possible REFER problem?

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 8 Nov 2000 18:15:10 -0600 (CST)

Eric Tremblay writes:
>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.

<explanation of why this won't necessarily work snipped>

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

Obviously, the most useful application of this latter piece of information
is routing of subsequent messages for a particular call -- but I don't
see why it absolutely MUST be the only use for this information.

For the "Contact" information to be useful in any way, it needs to be
something that can be routed when used as a Request-URI; it wouldn't
work for "BYE" messages otherwise, right? 

So, if the transferee were passed this information to be used as 
the Request-URI, there should be no discernable problems with the 
INVITE (or other appropriate method) arriving at the partcular 
instance of the desired resource on a particular device.

Since no one else has raised this point, I'm going to assume that
I'm too blind to see the elephant in the room. So, could someone 
explain *why* using a Contact URI in this manner would be inappropriate
behavior?

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

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

---

From: "Robert Sparks" <[email-masked]>
Date: Mon, 13 Nov 2000 13:30:33 -0600

I had to rethink this whole conversation to respond,
and as part of the process captured the following notes.
Hopefully, they'll be a helpful summary:

The scenario that started this discussion consisted of
A calling B, A puts B on hold, A calls C, A then wants
to transfer B to C and try to ensure that the same B
gets the same C-endpoint that A was talking to.

The question was whether the Refer-To header in the REFER
message that A sends to B should contain the URL that A
used to reach C in the first place, or the URL that C
returned in the 200 OK to A's INVITE.

The Contact that C provided to A is only guaranteed to make
sense in the context of A's session with C. For example, the
hostname may be in a private namespace in a company's LAN.
A and B would both fail if they did a DNS lookup on it, but
the last proxy on the Route before that contact would have
no problems with it.

Even if C gave A a contact that A could resolve, there
is no guarantee that C will honor that contact outside the
call leg that A and C have set up.

Jonathan's suggested method is to place the contact that
C gave to A in the Accept-Contact header to increase the
probability (not ensure) that B reaches the same C-endpoint
that A did.

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.

RjS

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Adam B. Roach
> Sent: Wednesday, November 08, 2000 6:15 PM
> To: Eric Tremblay
> Cc: 'Jonathan Rosenberg'; [email-masked]'; Eric Tremblay;
> [email-masked]'
> Subject: Re: [SIP] Possible REFER problem?
>
>
> Eric Tremblay writes:

---

From: Billy Biggs <[email-masked]>
Date: Mon, 13 Nov 2000 14:11:21 -0600

Robert Sparks ([email-masked]):

> [...]
> 
> The scenario that started this discussion consisted of A calling B, A
> puts B on hold, A calls C, A then wants to transfer B to C and try to
> ensure that the same B gets the same C-endpoint that A was talking to.
> 
> The question was whether the Refer-To header in the REFER message that
> A sends to B should contain the URL that A used to reach C in the
> first place, or the URL that C returned in the 200 OK to A's INVITE.

  C may have called A, in which case the well known URL is unknown.  You
can't use the From here either since it is outside of the scope.

> sense in the context of A's session with C.  [...]

  I disagree with this.  The contact that C provided has to be available
at least for new calls within the local namespace, and if not, then
whatever translator in the middle (outbound proxy, transparent
masquerade host or whatever) has to know to check the Refer-To header
and mangle it also.

  Otherwise this gets too complicated.

> Jonathan's suggested method is to place the contact that C gave to A
> in the Accept-Contact header to increase the probability (not ensure)
> that B reaches the same C-endpoint that A did.

  And put that as a header parameter in the URL given in the Refer-To
header?  This seems like a big hack, especially since the well known URL
may not be known.

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

---

From: "Robert Sparks" <[email-masked]>
Date: Mon, 13 Nov 2000 14:32:01 -0600

> can't use the From here either since it is outside of the scope.

Interesting thought. Really unusual preconditions though. "Let me transfer
you to this other person that just called me". In that case, the contact
they've provided is the best you've got unless you can get better
information
through another channel.

>   Otherwise this gets too complicated.

I'm not sure what/who you're disagreeing with? The contact that C provides
has only to be valid for subsequent requests in that call-leg. (I can't
imagine
anyone actually implementing it that way, but afaict, that's all the spec
requires).

> header?  This seems like a big hack, especially since the well known URL

You didn't comment on the hybrid approach at the end of the message. I
think it addresses the case you are wanting to solve (as the primary
usage even).

RjS

---

From: Billy Biggs <[email-masked]>
Date: Mon, 13 Nov 2000 15:26:56 -0600

Robert Sparks ([email-masked]):

> > > The scenario that started this discussion consisted of A calling
> > > B, A puts B on hold, A calls C, A then wants to transfer B to C
> > > and try to ensure that the same B gets the same C-endpoint that A
> > > was talking to.
> > >
> > > The question was whether the Refer-To header in the REFER message
> > > that A sends to B should contain the URL that A used to reach C in
> > > the first place, or the URL that C returned in the 200 OK to A's
> > > INVITE.
> >
> >   C may have called A, in which case the well known URL is unknown.
> > You can't use the From here either since it is outside of the
> > scope.
> 
> Interesting thought. Really unusual preconditions though. "Let me
> transfer you to this other person that just called me". In that case,
> the contact they've provided is the best you've got unless you can get
> better information through another channel.

  It's not unusual when you consider the general problem: how to excuse
yourself from a 3-way call.

  I have two active call legs and I want to join the two remote
endpoints using REFER.  Everything else is just a special case of this
problem.

> > > The Contact that C provided to A is only guaranteed to make sense
> > > in the context of A's session with C.  [...]
> >
> >   I disagree with this.  The contact that C provided has to be
> > available at least for new calls within the local namespace, and
> > if not, then whatever translator in the middle (outbound proxy,
> > transparent masquerade host or whatever) has to know to check the
> > Refer-To header and mangle it also.
> >
> I'm not sure what/who you're disagreeing with? The contact that C
> provides has only to be valid for subsequent requests in that
> call-leg. (I can't imagine anyone actually implementing it that way,
> but afaict, that's all the spec requires).

  Since the call between A and C is pretty much guaranteed to be still
going on, this pedantic UA seems even more ridiculous.  For the sake of
interoperability the URI that you put in a Contact should be available
for requests from other UAs, and if you're a multi-user phone or
gateway, it should probably also have a username.

> > > Jonathan's suggested method is to place the contact that C gave to
> > > A in the Accept-Contact header to increase the probability (not
> > > ensure) that B reaches the same C-endpoint that A did.
> >
> >   And put that as a header parameter in the URL given in the
> > Refer-To header?  This seems like a big hack, especially since the
> > well known URL may not be known.
> 

  The hyrbid approach you suggested was:

  I found another problem with part 2:  The proxy now has to do some
funky matching to try and correlate the Contact provided with those
known.  Pretty crazy, since in your scenario it's not the same as how it
registered, but I guess in some cases it is somehow similar (different
port, host in the same subnet, etc).

  Of course, this is all implementation specific- there are probably
other ways of convincing the transfer to work if it fails.  It would be
nice to eventually define some body type to indicate to the referrer why
the call failed (application/sip-status?).

  However I would NOT recommend attempting step 2 as it is error-prone
and only solves a very unlikely specific case.

---

From: "Robert Sparks" <[email-masked]>
Date: Mon, 13 Nov 2000 16:29:35 -0600

> port, host in the same subnet, etc).

Actually, in this scenario it would likely be _exactly_ what was registered.
This is one of the premises of caller-prefs, yes? The funky matching is
defined in that draft. If for some reason, it wasn't registered, or the
proxy involved didn't implement caller-prefs, the proxy's going to route
to the same places it would have without the hint.

> and only solves a very unlikely specific case.

We _must_ be talking past each other here. What's proposed at 2 is a
straightforward use of the caller-preferences mechanism. At the absolute
worst, 2 will result in exactly what you would have gotten if
the REFER to B contained only C's well known URL.

---

From: Billy Biggs <[email-masked]>
Date: Mon, 13 Nov 2000 17:04:12 -0600

Robert Sparks ([email-masked]):

> >   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.
> >
> > funky matching to try and correlate the Contact provided with
> > those known.  Pretty crazy, since in your scenario it's not the
> > same as how it registered, but I guess in some cases it is somehow
> > similar (different port, host in the same subnet, etc).
> 
> Actually, in this scenario it would likely be _exactly_ what was
> registered.  [...] At the absolute worst, 2 will result in exactly
> what you would have gotten if the REFER to B contained only C's well
> known URL.

  I'm sorry, there were two discussed scenarios where this would be
needed, and I got confused:

  Case 1 (what you meant):

> [...] the hostname may be in a private namespace in a company's LAN.

  -> Refer-To: <sip:[email-masked]?Accept-Contact=private.addr>

  The refer failed because the Contact was a private address, and
hopefully it was the same address used to register at well-known.com.
You are correct, this will help well-known.com reach the private
address.  Apologies.

  Case 2 (my confusion):

> [...] The contact that C provides has only to be valid for subsequent
> requests in that call-leg.

  -> Refer-To: <sip:[email-masked]?Accept-Contact=addr:31337>

  Here we have a UA which fork()s off a new process per call which has
its own port.  Caller-preferences does nothing, but you are correct in
that it doesn't hurt.

  However, I think this just makes the algorithm over-complicated.
You're making an assumption about why the original REFER failed when
there are many other possible explinations:

 - The REFER target returned a 486 or other error response
 - The REFER target has a sever failure
 - Some authentication failure
 - ...

  It also only works if A initiated the call to C.

  Like I said, implementations are free to try harder, but I wouldn't
recommend it.

  Note that I plan on hacking my masquerade module code to also mangle
the Refer-To header.  That's the bane of the NAT implementor- to forever
be modifying the NAT code to handle the new protocol or protocol
extension.