I think the point is just that parallel forking is very badly supported
in SEMS in general. Concerning what we should do, this clear that we
have somehow create or simulate a second UAS. The bigger issue is: how
do we implement this so that app plug-ins have a chance to do the right
thing?
In the transaparent B2BUA case, it is still very simple, as we do not
have to maintain the multiple early dialogs (just forward the message
correctly). But when SEMS is acting as a full UAC, with some script or
c++ app behind it, it hard to make this available to the app. We could
just handle the first final response, and BYE all the other dialogs,
without letting the app know about them.
Frankly, it an issue that I banned from my mind a couple of month ago...
Any contructive input is welcome! (included some code snipplets)
-Raphael.
Iñaki Baz Castillo wrote:
El Viernes, 28 de Noviembre de 2008, Stefan Sayer escribió:
ok, but how do you think a b2bua should handle this? modify the
originator in all the replies to match the one of the first reply?
Hi, as I said, this issue wouldn't occur if the To_tag in *each* response sent
to leg_A would just depend on To_tag in *each* response received in leg_B,
just it.
This would involve B2BUA becoming various UAS in leg_A (not just one as now),
this is: one UAS in leg_A for each UAS detected in leg_B (each different
To_tag received).
If not, the behaviour is wrong since all replies in leg_A should have the same
SDP, and of course, a pure SIP B2BUA can't handle it (or well, SEMS could do
it but it's not the point).
I don't know if I've fully replied your question. Best regards.
_______________________________________________
Semsdev mailing list
Semsdev@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/semsdev
