Subject: [SIP] Call Transfer Using REFER Method.

From: "Gross, Gerhard" <[email-masked]>
Date: Mon, 5 Mar 2001 11:15:41 -0800

Ed,

Good questions. The two drafts you mention,
"call-auth" and "gross-sipaq" target two
different problems. "gross-sipaq" primarily deals
with solving the inter-domain AAA problem. From
my understanding the "call-auth" draft deals
with intra-domain authorization.

In the "call-auth" draft, auth tokens
are generated and used independently
at each domain - they are not transported to the
other domain(s). The auth tokens are to convince
the edge router in the same domain that some governing
entity in that domain (PDP) has OK'd BW reservation
for a particular SIP session. I'm not sure how this
model works when other (non-SIP) applications want
to reserve bandwidth.

The model in "gross-sipaq" generates an auth token
through a clearinghouse and passes that token to
the other domain(s) to convince them that an appropriate
business relationship exits with the clearinghouse. This
facilitates end to end transaction settlement (accounting,
auditing, charging, billing, etc.) Of course, this is
only necessary if a billable service is used by the
session such as gateway services, bandwidth reservation,
etc. In this case, signaling must go through the SIP proxy
and the AAA/policy server. I don't think this alone
qualifies the SIP proxy as a B2BUA. It *controls* the
session only in the sense that it may not allow a session
to proceed due to a policy based decision (outsourced
to a AAA/policy server). But after that decision is
rendered, it releases control.

In the transfer call flow of the preceeding email,
the proxy serves the purpose of aiding in the
transfer process (I think). At any rate, that is
independent of AAA/policy messaging. If AAA/policy
messaging were needed in the transfer call flow,
additional messages between the proxy and one or
more AAA/policy servers would be required. They are
not shown because that was not the focus of the
question.

I hope that makes the waters clearer instead of
murkier :)

-Gery

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ed Ellesson
Sent: Friday, March 02, 2001 4:11 PM
To: 'Jonathan Rosenberg'
Cc: Ragunath Devarasu; [email-masked]'
Subject: RE: [SIP] Call Transfer Using REFER Method.

Jonathan,

My question is related to this recent exchange of notes on the REFER Method:

Should we be changing the terminology in other SIP drafts to refer to SIP
Proxies as B2BUA's, when the required functionality demands that all Invites
must be routed through the SIP Proxy?

I apologize if I have missed an earlier exchange on the list that clarifies
this.  If so, please feel free to just point me to that exchange.  I'm
coming up to speed on the issues involved in applying QOS and Policy to SIP
managed sessions and the RTP flows that are set up in the context of those
sessions.  I have read through this exchange with interest, because I am
trying to reconcile the position about SIP proxies stated in your note, with
the positions taken in other sip drafts, including the sip working group
draft "SIP Extensions for Media Authorization"

http://www.ietf.org/internet-drafts/draft-ietf-sip-call-auth-01.txt

According to that draft, (see Figure 1), the Invite from the UAC must go to
the Outgoing Proxy in order for Client Authentication and Call Authorization
to occur, and in order for the OP to return an Auth. Token to the UAC which
gives the User Agent the ability to insert Media-Authorization info into an
RSVP Path message.

If the Invite from the Transferee to the Transfer Target does not have to go
through an Outgoing Proxy, how does the bandwidth allocation authorization
get communicated?

Does this mean that the OP in this draft is really a "B2BUA"?

I noticed the same problem with the following draft, which is not a working
group draft, but perhaps those authors would like to chime in as well?

http://www.ietf.org/internet-drafts/draft-gross-sipaq-00.txt

Under figure 1, this document states:

"The SIP proxy acts as a policy enforcement point, PEP, for IP communication
sessions that use SIP."

How can the SIP proxy act as an enforcement point, if the session setup
messages, such as INVITE do not touch it, in all cases?
Does this mean that the SIP proxy in this draft should also be called a
"B2BUA?"

Ed Ellesson
LongBoard, Inc.
[email-masked]
919-361-3230

 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:[email-masked]]
Sent:	Thursday, March 01, 2001 2:41 AM
To:	'Ragunath Devarasu'; [email-masked]'
Subject:	RE: [SIP] Call Transfer Using REFER Method.

Comments below.

> -----Original Message-----
> From: Ragunath Devarasu [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 5:58 PM
> To: [email-masked]'
> Subject: [SIP] Call Transfer Using REFER Method.
>
>
> Hi All,
>
> 	We are having a hard time trying to figure out how to make the
> Transferee send the Invite to the Transfer Target through the
> proxy when
> REFER is used to transfer the call. Could you shed some light
> on how this
> can be achieved.
>
> Transferee	    Transferor       Proxy		Transfer Target
>
> Invite|--------------------------->
>       |<----------------------- 100 Trying
>       |             <---------- Invite
>       |         200 -------------->
>       |<----------------------- 200
> Ack   |--------------------------->
>       |             <---------- Ack
>       |        Invite(c=0)-------->
>       |<----------------------- Invite(c=0)
> 200 Ok|--------------------------->
>       |             <---------- 200 Ok
>       |         Ack -------------->
>       |<----------------------- Ack
>       |            Invite(TT)----->
>       |                         Invite ------------->
>       |                           <--------------- 200
>       |                 <-------- 200
>       |        Ack	-------------->
>       |                           Ack -------------->
>       |        Bye	 ------------->
>       |                           Bye -------------->
>       |                           <--------------- 200
>       |                 <-------- 200
>       |        Refer  ------------>
>       |<------------------------- Refer
> 200 Ok|--------------------------->
>       |            <------------- 200 OK
> Invite|--------------------------------------------->
>       |<------------------------------------------- 200 Ok
> Ack   |--------------------------------------------->
> Bye   |--------------------------------------------->
>       |<------------------------------------------- 200 Ok
>
> 	We would like to see the last Invite and Bye go through
> the proxy
> too
> so that the proxy can control that call. Would a Record-Route
> in the Refer
> help me achieve this goal ? Or a route header embedded in the
> referred-to
> header ? Is the transferor mandated to use the route header
> thus provided?

First off, I would advise you to think about why you want the proxy to
"control the call". Proxies don't control calls. THey route calls. If you
want a centralized system that controls the calls and can do anything you
want, you aren't talking about a proxy any longer, but rather a B2BUA.

An invite triggered by refer can be forced through a specific proxy by
inclusion of a Route header parameter in the referred to URL. However, the
UA sending the REFER inserts this URL. I suppose the proxy could modify it,
but its not pretty and there may be odd failure scenarios.

-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

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Ed Ellesson <[email-masked]>
Date: Mon, 5 Mar 2001 14:42:59 -0500

Gery, 

Your explanation helps a lot.  Thank you!  

It seems to me, based on your explanation, that in both cases, the
intra-domain call auth, and the inter-domain call auth, the Invite message
for the transfer leg of the call *needs to go through the originating
proxy*, in order for the proxy to do what it needs to do.  

I also agree that the proxy is not controlling the call, but, nevertheless,
the flow through the proxy is needed, to support the call auth function. 

The problem with these flows in the transfer scenario, as I understand it,
is that *the transfer leg's Invite message  does not ever go through the
proxy*, unless we do something which Jonathan seems to think is cruel and
unusual for a proxy, but not for a B2BUA.  

Is that how you understand it?  

Jonathan, I hope I have not mis-stated your position.  

Ed

 -----Original Message-----
From: 	Gross, Gerhard [mailto:[email-masked]] 
Sent:	Monday, March 05, 2001 2:16 PM
To:	[email-masked]'
Subject:	[SIP] Call Transfer Using REFER Method.

Ed,

-Gery

-----Original Message-----

Jonathan,

Ed Ellesson
LongBoard, Inc.
[email-masked]
919-361-3230

 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:[email-masked]]
Sent:	Thursday, March 01, 2001 2:41 AM
To:	'Ragunath Devarasu'; [email-masked]'
Subject:	RE: [SIP] Call Transfer Using REFER Method.

Comments below.

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Mar 2001 17:02:01 -0500

> From: Ed Ellesson [mailto:[email-masked]]
> Sent: Monday, March 05, 2001 2:43 PM
> To: 'Gross, Gerhard'; [email-masked]'

No, that is simply not true.

The INVITE triggered by a transfer is a normal INVITE. If the transferred
party is configured to use a local outbound proxy, then the INVITE is sent
to that proxy. That proxy can return a token for media authorization, as per
the DCS drafts, or do whatever else it likes for that call. The key point is
that this proxy needn't be the same proxy that handled the incoming call
from the original caller to the transferred party. 

I see no particularly compelling reason why, if proxy P1 was involved in a
call from A to B, proxy P1 must be involved in a transfer invoked by A, to
transfer B to C. If, for some reason, you believe that this is super
critical, it is this case that I am arguing that a B2BUA is more
appropriate.
 
> the flow through the proxy is needed, to support the call 

Well, a call through SOME proxy is needed. I don't see why it need by the
SAME proxy.

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Mar 2001 17:04:39 -0500

> From: Subir Saha [mailto:[email-masked]]
> Sent: Monday, March 05, 2001 4:00 PM
> To: Ed Ellesson; 'Gross, Gerhard'; [email-masked]'
> Hi All:
> It will be nice to know whether B2BUA is 100% protocol 
> compliant entity? I
> am getting the picture that makes B2BUA as something which 
> can do which
> eever way it wants to!
> Subir Saha
> LongBoard Inc.

The spec does not define a B2BUA. It doesn't have to. The spec defines user
agent servers. It also defines user agent clients. A B2BUA is simply a
device that is a compliant UAS for incoming calls, and then a compliant UAC
for outgoing calls. There is some logic in the middle which is your choice.
You can think of it as a gateway. We have SIP to ISUP gateways, and SIP to
H.323 gateways. THis is a SIP to SIP gateway. Its completely call stateful,
and is a central point of failure in a call flow. Its state must be
replicated for fault tolerance. All the same stuff that is true for
softswitches and gateways. 

-Jonathan R.

---

---

From: "Gross, Gerhard" <[email-masked]>
Date: Mon, 5 Mar 2001 14:55:52 -0800

The point of inter-domain AAA is to make
sure that all endpoints that receive billable
services (like reserved BW) are legitimately
associated with authenticated parties to ensure
correct transaction settlement. In this way
all providers offering the billable service(s)
get their money.

As Jonathan pointed out, this does not mean
that signaling must go through the *originating*
proxy during the transfer. If the session
between transferee and the transferor (the two
parties involved in the original call) is already
established (in the AAA model), authentication
has already been established between them.
It is the transfer target, the new endpoint, that
is not yet authenticated/authorized. Signaling
during the transfer must go through the proxy
associated with that new endpoint, wherever it
may be. Chances are it is not the original proxy.

Proxies in this AAA model do not have to be B2BUA,
and therefore do not have to be call stateful.
Just use them as PEPs to get authorization decisions
from PDPs. The PDPs will need to be call stateful
and communicate with the routers when bandwidth
is no longer reserved (for example when the call
terminates or the reservation removed). In this way
the PDPs collect usage information of a billable service
(BW reservation) and can propagate that information
to an appropriate entity such as a clearinghouse
for final transaction settlement. But all this goes
on independent of, and unassociated with SIP.

Gery

    --- Ask me about my lobotomy

> Sent: Monday, March 05, 2001 11:43 AM

---

From: Ed Ellesson <[email-masked]>
Date: Mon, 5 Mar 2001 18:57:24 -0500

Jonathan, 

Thank you for your reply and your patience.  Believe it or not, I think I am
beginning to understand!

In your first reply to this thread, dated Thursday, March 01, 2001, you
stated:  

>Proxies don't control calls. They route calls.

I may have read too much meaning into that statement, and please forgive me,
if I have.  

I thought that, by that statement, you meant that if the originating UA has
enough information to go directly to the transfer target address, without
going to *any* proxy, it was free to do so, even if it was normally
configured to go to a local proxy to get the target routing information,
since the REFER has already given it all the routing info it needs.

From your last note, I see that I was probably mistaken in that assumption:

>to that proxy.

Right.  That's just what I want to have happen.  I never intended for the
second Invite to go through the same proxy as the first Invite.  I just
wanted to be sure that the second Invite would go through whatever outbound
proxy that the Transferee would normally be configured to go through for its
Invites, be they involved in a Transfer or not.  So, I think we are now
getting down to the crux of the issue, and my question is thus:

Where is it written, in the "SIP Scriptures", that a SIP device, be it phone
or IAD, MUST be configurable such that your above statement is always true:
"If the transferred party is configured to use a local outbound proxy, then
the INVITE is sent to that proxy."  ?  

The reason I ask, is that it seems to me, that an implementor of SIP phones
or IAD's COULD make their phones configurable to use a local proxy in the
following way, and still be compliant with SIP orthodoxy, unless we render
your above statement explicitly, in some RFC, somewhere: 

-  IF the phone is configured to use a local proxy, and the address of the
target is not in the form of an explicit IP numerical address, THEN send the
INVITE to the local proxy, and, 

-  IF the phone is configured to use a local proxy, and the address of the
target *is* in the form of an explicit IP numerical address, THEN send the
INVITE directly to the destination target SIP device, without going through
the local proxy  (since the presence and explicit IP address info is already
known via the REFER message).  

I don't want the phone or IAD to operate that way, in the scenarios that we
have in mind.  In fact, I think the call-auth drafts also depend on the SIP
device not behaving that way.  

So, is there somewhere we can write in a standards track document, that SIP
devices MUST be configurable to operate in a way that makes the following
requirement explicit: 

*All* Invites MUST go through a local proxy, if one is configured.  

(Or maybe it's a BCP or something, but it seems to me like we need to make
this dependency explicit, for those cases where we need the operation to
proceed according to your statement, above.)  

If this is already written down somewhere, I apologize.  Please send a
pointer.  

Thanks, 

Ed Ellesson
LongBoard, Inc.

From: 	Jonathan Rosenberg [mailto:[email-masked]] 
Sent:	Monday, March 05, 2001 5:02 PM
To:	'Ed Ellesson'; 'Gross, Gerhard'; [email-masked]'
Subject:	RE: [SIP] Call Transfer Using REFER Method.

 

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Mar 2001 23:28:02 -0500

> Sent: Monday, March 05, 2001 6:57 PM
> To: 'Jonathan Rosenberg'; 'Gross, Gerhard'; [email-masked]'

Handling of an INVITE triggered by a REFER is no different than a regular
INVITE. If the UA is configured to use a local outbound proxy, then it will.

However, be warned: if you are generating billing records off of these
proxies (generally dangerous for things of the per-minute variation), its a
good incentive to build a UA that doesn't bother with local outbound
proxies.

> the INVITE is sent to that proxy."  ? 

Nowhere is this written; I see no need to restate every INVITE processing
rule just for the case where an INVITE is triggered from a REFER. INVITEs
can be triggered lots of different ways, including web clicks, a user
entering the URL, etc. All obey the same rules. I have no problem adding
some text to the REFER draft which says something like, "a triggered INVITE
obeys normal rules for sending an INVITE as per RFC2543".

> known via the REFER message).  

This is a configuration and implementation detail. I see no reason why it is
wrong for a phone to do that. If you are depending on making a buck on
whether phones do this, you are in big trouble.

> device not behaving that way.  

It is better phrased thusly; a phone which doesn't bother with its local
outbound proxy won't get QoS service. Seems like the choice belongs to the
user of the phone.

> *All* Invites MUST go through a local proxy, if one is configured.  

I think text like this is a bit dangerous. It makes vendors or providers
somehow think that the SIP protocol police can guarantee that the end users
get billed for service. It also doesn't make sense for a phone which has two
providers, for example, and chooses one based on some cost related
configuration. Both have local proxies, yet clearly both cannot be used...

-Jonathan R.
---

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Mar 2001 15:28:50 -0000

I agree with what Jonathan says, but I believe it would be appropriate to
include that much in the bis draft.

While we do not need to say what a B2BUA does beyond this, we should define
the concept, and state that it does act as a UA in both directions. It is
also important that readers know that other capabilities are outside the
scope of the specification.

Presumably, Jonathans definition means that a proxy cannot change its mind
halfway through a session, therefore an intervening entity is either a proxy
or a B2BUA.

If people don't object to this, I will try and draft some appropriate text.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Jonathan Rosenberg[SMTP:[email-masked]]
> Sent: 	05 March 2001 22:04
> To: 	'Subir Saha'; Ed Ellesson; 'Gross, Gerhard';
> [email-masked]'

---

From: Ed Ellesson <[email-masked]>
Date: Tue, 6 Mar 2001 11:09:58 -0500

Jonathan, 

>I have no problem adding some text to the REFER draft which says something
like, "a triggered INVITE obeys normal >rules for sending an INVITE as per
RFC2543".

Thanks, I think that would be a valuable addition to the REFER draft.  

>proxies....

>...It is better phrased thusly; a phone which doesn't bother with its local

I understand your position.  I now see more clearly what is assumed to
motivate the user (and the developer of a SIP phone UA) to make use of an
outbound proxy, when it is configured.   I also think that the motivational
situation can be different in a corporate intranet, compared to that of a
public Internet service, but I also understand that your concern can have
merit, in both sets of circumstances.  

This thread has been very helpful for me.  I thank you for spending the time
and the attention on the SIP list, in order to clarify these points for me.

Thanks!

Ed Ellesson
LongBoard, Inc.

 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:[email-masked]] 
Sent:	Monday, March 05, 2001 11:28 PM
To:	'Ed Ellesson'; Jonathan Rosenberg; 'Gross, Gerhard';

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Mar 2001 16:53:09 -0500

> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 10:29 AM
> To: [email-masked]'; 'Jonathan Rosenberg'

I agree. It was already in my to do list to add such text.

> If people don't object to this, I will try and draft some 

Feel free; send me whatever text you come up with.

Thanks,
Jonathan R.

---