Raphael Coeffic writes: > Parallel forking is somehow more complex, due to the fact that SEMS > supports only one SIP dialog per session. This means that SEMS does not > behave correctly if the INVITE is forked later on (for example using a > SIP proxy).
raphael, my call center app has not control on if outbound proxy forks the call or not. when its onOtherReply function receives a 1xx reply, it simply resets its provisional reply timer and returns. are you saying that it does not work if it receives an early dialog reply (eg. 180 or 183) from many UAs? if not, then i consider it a bug in sems. > To be able to support that, we can either: > - modify the Am*Session classes to support multiple sip dialogs, > - or, create one session instance per dialog and keep there a list of > the other sessions (just like AmB2BSession does, but with more sessions). > > The first option would probably allow for simpler application > programming, as you could directly access the other dialogs' pointers. > But in my opinion, the second option would be better suited for your > scenario, and would allow for merging calls as well, as described in > earlier emails. i don't care how it is done as long my ivr app does not need to know anything about it, i.e., the complexity is hidden in the wrapper. the only thing this kind of simple app cares about is if it receives a 200 ok before its final reply timer hits. -- juha _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
