UAC and UAS are terms that are meaningful in the context of a single transaction. They are essentially never meaningful in the context of a component that does multiple transactions in order to accomplish meaningful work.
It makes no sense to talk about a B2BUA in the context of a single transaction. It obviously can't be a B2BUA without doing at least two transactions, and it can't do anything meaningful with only two.
In practice a B2BUA will have at least two "sides" that it is tying together. On each side it will sometimes act as UAC and sometimes as UAS. When it receives a request on one side (acting as a UAS) it will often act as a UAC to send a corresponding request on the other side. But other actions, like sending a BYE to both sides, are also in scope.
Paul
Ganesh Jayadevan wrote:
Thanks to everyone who responded to my question.
What I gather:
1. We can be precise when we refer to the UAC-UAC concatenation: b2buac.
2. One reponse favored sticking to the precise definition for b2bua in rfc3261 as the
concatenation of UAS-UAC.
3. Two other responses were ok with calling UA-UA as a b2bua.
While I don't disagree with 2 (I was hoping 3 was the answer), in a follow-on
call where an INVITE comes into a UAS and an INVITE is sent out using a UAC
(and therefore a UAS-UAC concat.), if the application decided to tear down both
active dialogs, it would then function as a UAC-UAC.
To sum up, while rfc3261 only refers to UAS-UAC while describing a b2bua,
we would not be in violation of the defintion to generalize it to UA-UA.
Any dissent?
Thanks, Ganesh
Brett Tate wrote:
Would it be incorrect to use the term b2bua to refer to a UAC-UAC concatenation?
If the mentioned UAC endpoints truly never act as a UAS within a given dialog,
b2buac would be the better definition.
However to truly satisfy such a definition would
be rare since it would need to drop incoming requests traversing the dialog or provide a Contact of another device to ensure that it
would not need to act as a UAS.
Note that a 3pcc b2bua which intends to reject all dialog related incoming requests with something like a 405 or 403 is still acting a UAS when it rejects the requests. Thus it would still be considered a b2bua instead of a b2buac.
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
------------------------------------------------------------------------
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
