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. Then the B2BUA has to be designed in a way so things works. It can choose to collect the pre-paid DTMFs before contacting the IVR, or something else. It's not up to us to design those B2BUAs. >You are talking about two applications resident in the same >UA. That is usually outside the scope of our discussions. I would hope so, but I think Eric brought this case up at one point. >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. Fine, so it's not a problem then. Regards, Christer _______________________________________________ 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
