Subject: RE: [Sip] B2BUA

From: [email-masked]
Date: Tue, 3 Dec 2002 19:59:56 +0200

Brian,

inline.

> Of course these things are never so simple.
> On an "end system mixed" conference, an INVITE
> from a new participant triggers Re-INVITES to
> existing participants.  Depending on details,
> a focus could hold the response from the INVITE
> of the new participant until it receives responses
> from all existing participants (new CODEC negotiation
> for example).  That meets your definition of B2BUA.
> 
> On the other hand, a centrally mixed conference
> would not normally trigger Re-INVITES.  Does that
> mean that an end-system mixed focus is a B2BUA
> but a centrally mixed focus is not?  Hard to
> differentiate.  With both of them, a state
> change, signaled by, say a NOTIFY from one to
> the focus triggers NOTIFIES to (possibly a
> subset of) the other participants, so that
> would meet the definition.  Would you call
> that a change in roles?

I agree, a conference server could assume both UA and B2BUA roles, as well as proxy and redirect server roles depending on the system, application, request, and so on.  But whether a focus is a UA, a B2BUA, or both is somewhat besides the point.  The roles need to be defined so that B2BUA behavior is distinct from UA behavior.  The end-point can then use one that best fits its purpose.

Cheers,
Aki

> 
> Brian
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, December 03, 2002 12:13 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [Sip] B2BUA
> > 
> > 
> > Inline.
> > 
> > > The key thing about a B2BUA is that it looks like a UA to whatever
> > > it is connected to (on both sides).  So, a conference server
> > > looks like a UA to each of it's ports, and it has at least two of
> > > them, and there is some "magic" between them.  If you look at the
> > > concept of the "focus" from the conferencing work, it is a
> > > thing that has a bunch of two ended SIP calls, one with each
> > > participant.  Each participant thinks it is talking to a UA.
> > > While some messages sent from a participant to a UA might be
> > > consumed by the UA (state changes), often, a message will trigger
> > > messages from the focus to other participants.
> > 
> > This just generalized the B2BUA to cover any normal UA 
> > behavior. Example, I get a MESSAGE from a friend to my UA, 
> > based on which decide to call another friend by sending an 
> > INVITE from that UA. This I think is quite normal UA 
> > operation, the "magic" being me via my UI.
> > 
> > > This seems, to me, to meet the definition of B2BUA in 3261,
> > > and more strongly meets proposed changes in the definition.
> > > Of course, it really doesn't matter if you consider the focus to
> > > be a B2BUA or not.
> > 
> > Hmm... Let's think of the B2BUA as 'in-UA' concatenated with 
> > 'out-UA'. By definition:
> > 
> > 1) in-UAS receives request,
> >    <Magic happens>
> > 2) out-UAC sends request'
> > 3) out-UAC receives response'
> >    <Magic happens>
> > 4) in-UAS sends response
> > 
> > (The same process happens with requests going from 'out' to 'in')
> > 
> > Within this B2BUA, 'in-UAS' shares magic with 'out-UAC', and 
> > 'in-UAC' shares magic with 'out-UAS'. However, if (as you 
> > state above), 4) follows immediately after 1), it's no longer 
> > a B2BUA, but a plain old UA, IMHO. 
> > 
> > Cheers,
> > Aki
> > 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip