RE: [Sip] B2BUA & Max-Forwards

[Adam Roach <adam@dynamicsoft.com>]

You see, that's why I rephrased the question to be more
precise. The original question didn't make a whole lot of
sense, because the term "called party" is somewhat
counter-intuitive when applied to B2BUAs.

      Invitee, Invited User, Called Party, Callee: The party that
         receives an INVITE request for the purpose of establishing a
         new session.  A callee retains this role from the time it
         receives the INVITE until the termination of the dialog
         established by that INVITE.

In RFC3261 terms, the answer to Radhika's question, "who has been the
called party?" is "both UAS(b) and UAS(c)". They both receive the
INVITE, and establish a session. These sessions are, from a protocol
perspective, unrelated -- although they're obviously related by
some application logic.

But "both" would have been a flip answer, and it would be answering
a question that Radhika obviously did not intend to ask.

That notwithstanding, even using the colloquial definition you
seem to have in mind (which apparently has the constraint that
the "called party" device has a user sitting in front of it, or
has something to do with some personal desire held by the calling
party, or something like that), your assertion is demonstratably
false.

Take, for example, the situation in which User A (at UAC(a))
calls User B (at UAS(b)). They have a brief discussion, and
user B decides that he wants to add User C to the call;
using whatever interface is available, User B instructs his
client do so: User B (at UAC(b)) sends an INVITE request to
User C (at UAS(c)). User B decides to drop out of the call,
but instructs his device to keep the call up until one of
the parties disconnects.

So User B's device, which was obviously the called party in
the initial phase of the call (by either the 3261 or any
reasonable and most unreasonable colloquial definitions), is
rather clearly acting as a B2BUA.

/a

-----Original Message-----
From: Padma Suresh [mailto:padma_suresh@hotmail.com]
Sent: Wednesday, December 04, 2002 18:17
To: adam@dynamicsoft.com; rrroy@att.com
Cc: sip@ietf.org
Subject: RE: [Sip] B2BUA & Max-Forwards


For UAC (a) UAS (c) is the intended called party in the call. We have to
define the intended party in a call when a B2BUA is involved. B2BUA IS an
intermediate network element. It acts as some kind of a controller for a
domain. It is not the called party in any call. 
Regards
Padma
>From: Adam Roach 
>To: "'Roy, Radhika R, ALASO'" , Adam Roach 
>CC: sip@ietf.org 
>Subject: RE: [Sip] B2BUA & Max-Forwards 
>Date: Wed, 4 Dec 2002 16:58:14 -0600 
> 
> > UAC(a)--->UAS(b)===[application logic here]===UAC(b)--->UAS(c) 
> > 
> > [RRR] I like to know who has been the called party when 
> > UAC(a)) sent the INVITE message? Has it been UAS(b) or UAS(c)? 
> 
>I'm going to first need to clarify your question. 
> 
>The question I will answer is: "If an INVITE is sent through the 
>network described in this diagram, what is the value of the 
>Request-URI when UAC(a) sends it?" 
> 
>The answer is: it depends. In general, yes, it will probably be 
>either of UAS(b) or UAS(c). 
> 
> > [RRR] If the answer is UAS(c), the question is: Why the call 
> > has been routed to UAS(b) by UAC(a) in the first place? 
> 
>The most obvious of several plausible answers is: UAC(a) 
>has UAS(b) configured as a local outbound proxy. 
> 
> > [RRR] If the answer is UAS(b), probably UAC(a) does not care. 
> 
>About what? 
> 
>/a 
>_______________________________________________ 
>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip 
>This list is for NEW development of the core SIP Protocol 
>Use sip-implementors@cs.columbia.edu for questions on current sip 
>Use sipping@ietf.org for new developments on the application of sip 



Add photos to your e-mail with MSN 8. Get 2 months FREE*.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip