The b2bua must have a new transaction on its UAS started before its UAC can start a new transaction.
For example, its UAS must receive an INVITE before its UAC can generate an INVITE; and its UAS must receive a BYE before its UAC generates a BYE. However, the flow of these transactions might be in different directions. At the end of the day - whatever the RFC says - a b2bua needs to look like a SIP (and media) endpoint to both the parties with which it communicates. Alex On Wed, 2003-09-24 at 17:23, Ganesh Jayadevan wrote: > Alex, > > I realized that I need to actually broaden my question: > > UAC and UAS are roles a UA can play and therefore > if a UA can act as a UAC when sending out the initial INVITE, > it must also be able to act as UAS for an incoming BYE, for example. > > Would we be in error if we called a UA-UA as a b2bua? > This means it can do the following based on whether it is > receiving or sending requests: > > 1. UAC-UAC (to setup 3pcc calls) > 2. UAS-UAC (for initiating calls like follow-on calling) > 3. UAS-UAS (if both endpoint send BYE's -- conference-like situation) > > Thanks, > Ganesh > > Alex Zeffertt wrote: > > > The term b2bua has a rather narrow definition in Section 6 of rfc3261. > > > It refers to a UAS concatenated with a UAC for incoming requests into > > > the UAS. Would it be incorrect to use the term b2bua to refer to a > > > UAC-UAC concatenation? > > > > > > > > > > As I understand it, a softphone is typically both a UAC AND a UAS. This > > is because the softphone can both initiate calls and receive calls. A > > b2bua is also both a UAC and a UAS, but it will only initiate a call > > (i.e. act as a UAC) if it has received a call (on the UAS). It then > > maintains two seperate calls simultaneously, and pipes the streaming > > media between them. > > > > In this context it should be clear that a UAC-UAC concatenation wouldn't > > work as a b2bua, because it would have no way of receiving calls. > > > > Alex > > > > > > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
