On Mon, Feb 23, 2009 at 10:37 PM, M. Ranganathan <[email protected]> wrote: > 2009/2/23 Vito Korleone <[email protected]>: >> Hi everybody! I 'm a new member in this group of SIP people :-). >> >> So, here's my question, >> >> Why "we" need a B2BUA?? Can't we just have the same functionality if >> we replace him with a proxy and insert the Record Route field to trace all >> messages between the subscribers?? >> >> thanks, >> >> Nikos >> >> > > Depends upon the application. A b2bua puts state "in the network" > (logically) which is against the end to end design principle of SIP. > In particular, it breaks the three way handshake as the ACK cannot go > directly end to end. The ACK has to routed through the Back to Back > Dialogs. There is no way for the UAS to know that the UAC did not get > the OK. In practical terms, this means that an element in the middle > of the network can fail and one end (i.e. the end that sent the ACK ) > can have the mistaken impression that the other end saw it and thereby > "imagine" that the call has been successfully set up whereas in fact > it has not thus leaving the system in a "hung" state. Of course, if > there is a human answering the call, he will notice something bad and > hang up so many do not consider it such a big deal.
Though I should mention: A similar problem occurs when you send any In-DIALOG request that is hop to hop because the Dialog for a B2BUA in the middle of two end points, breaks the end to end association between the end points. These problems are circumventable using clever state management for the B2BUA but on the other hand, it needlessly complicates and potentially slows down the signaling and state management. Frequently, B2BUAs are used where there is no cause to do so. -- M. Ranganathan _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
