Hi Juha,
On 06.10.10 07:52, Juha Heinanen wrote:
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.
What will happen at the moment is that all provisional replies will be
passed to the session, whereby the first positive final reply will lock
the dialog. Any further reply (any type; containing either another
to-tag, or no to-tag) will be simple ignored, thus causing the remote
UAS' ACK timer to expire (or PRACK timer, if PRACK is used).
I won't play with words, but I do not consider it to be a bug, as I
never expected the code to work differently. But I will second you in
considering that SEMS should handle the case more nicely.
Now the question is: how should this be handled:
- first possibility: SEMS should wait for a positive final reply and
BYE the other dialogs. The issue is that some phones do not support BYE
in early state. CANCEL is not an option in such a case, as it would
cancel all the dialogs resulting from the forking (could be confusing
for some UAs).
- second possibility: SEMS should create a new dialog/session for each
different to-tag, and let the app choose which dialog(s) to pick. This
is much more challenging, as we have to either: support multiple dialog
per session, or create sessions on the fly and connect them back to the
caller session or conference status.
At the end, we might even need both possibilities, to be able cover all
types of applications.
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.
Does that mean that you would prefer the first possibility as described
above?
-Raphael.
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
