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
