I?aki, Yes, this is a pretty common mistake among B2BUA implementors. I must admit that OpenSBC suffers from the same. Generally, it was due to the misconception that a forking proxy will take care of canceling the remaining transactions after it has received the first successful final response. I have taken for granted the early dialogs that 1xx may generate. Hopefully I would be able to correct this in future versions of OpenSBC. On a related note. For those of you who want a quick way out in implementing a B2BUA, you might also want to check out OpenSIPStack. It is a B2BUA ready as well as RTP Proxy ready C++ SIP Stack. [Statement made with utmost respect to PJSIP Project and Benny P. (who has been really quiet recently? **poke**)] Joegen I?aki Baz Castillo wrote: > Hi, first of all I'm sorry for breaking the thread started by Saul with > subject "Some questions before starting a b2bua project", I'm subscribed to > this maillist right now. > > About the desired transparent B2BUA implementation, I would like to comment a > bug I've found in other, theorically, transparent B2BUA's: > > The problem occurs when a request arrives to the B2BUA (forming leg_A), the > B2BUA initiates a new request to a proxy as destination (forming leg_B), and > that proxy does parallel forking, so B2BUA receives several early-dialog > (different To_tag and different SDP in case of 183) in leg_B. > > For this to work, leg_A should act as a different UAS for each UAS detected in > leg_B, this involves that for each early-dialog in leg_B, leg_A should send > the same reply with different To_tag (respecting the SDP since it's > transparent). So finally there would be so many different To_tags in leg_A as > different To_tag received in leg_B. > If all the replies in leg_A share the same To_tag, but contain different SDP, > then we are breaking RFC 3261, since the SDP cannot be changed during an > early-dialog. > > I refer to the thread I opened reporting the bug in other maillist: > http://lists.iptel.org/pipermail/semsdev/2008-November/003309.html > > So the question is: do you think that the required correct behaviour would be > feasible with PjSIP? > > Thanks a lot. > > >
