Subject: RE: [SIP] Call Transfer Using REFER Method.

From: Subir Saha <[email-masked]>
Date: Mon, 5 Mar 2001 12:59:44 -0800

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.
-----Original Message-----
From: Ed Ellesson [mailto:[email-masked]]
Sent: Monday, March 05, 2001 11:43 AM
To: 'Gross, Gerhard'; [email-masked]'
Subject: RE: [SIP] Call Transfer Using REFER Method.

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,

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.

_______________________________________________
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: JAW-WU LIOU <[email-masked]>
Date: Mon, 05 Mar 2001 14:15:06 -0800

My understanding about "Back To Back UA" is that its an application of
UA and the implication is that an B2BUA handle two SIP calls. On one
end, it acts as a UAS (receive INVITE from the caller), then, instead of
forwarding this INVITE to the callee, it act as a UAC to callee, i.e.
create a new INVITE to the callee. From this point on, this B2BUA relay
(not fording but create a corresponding message) messages betwenn caller
& callee. This way, the B2BUA can receive a disconnect request from any
other applications and send BYE to both end to terminate the application
call (verse two SIP calls). Of cause, this is only one of the way to
implement 3PCC.

Jack