Christer Holmberg wrote:
Hi,
No. For subscribe/notify interaction, it is trivial:
whomever issues the subscribe gets the notify. Easy for the stack to
figure
out. For INFO
interaction, everything goes to call control. That works if your
model is pure softswitch/feature server, but not many folks are
doing that anymore.
Assume two applications are interested of the same event, so they both
subscribe to it. Now, how does the SENDER know to which subscription
to use for a specific application?
Is this a trick question? Or don't I understand you?
If two applications have concurrent and identical
subscriptions for the same event then they should both
receive equivalent notifications.
Yes, and that means that both applications will receive the event, even
if the sender only intended to send the event to one of the
applications.
So, in that case: if the same information is sent in an INFO, the
receiver will provide it to both application that has indicated to the
stack that they want that type of information to be dispatched to them.
I have lost my way in this conversation.
In the context of sub/not when we talk about multiple applications being
interested in the same event, they are typically not resident in the
same UA. For instance for DTMF we may have a pre-paid application acting
as a B2BUA and an IVR at the far end that also wants to interact with
the caller.
You are talking about two applications resident in the same UA. That is
usually outside the scope of our discussions.
In general the source if the info (the notifier or sender of INFO) won't
know where it wants to send the info, or that there might be multiple
consumers of it. In the case of sub/not it is told this by SUBSCRIBEs.
In the case of INFO there really isn't any point in it knowing if there
are multiple consumers, since that won't alter its behavior.
Paul
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
