Christer Holmberg wrote:
All we need is draft-subscribe-header-for-invite... :)
THis of course is predicated on the assumption that the same two parties
are the right ones to be involved in the subscription and the invite.
This works out ok for DTMF. It remains to be seen where else it is valid.
It might seem that it would be valid for the dialog event package. But
it might not be if the goal is to get consolidated event state for all
UASs of the same AOR. Its far from clear that the subscriber would know.
So there probably at least needs to be some way to accept the INVITE but
reject the bundled subscription. And in that case the caller needs to
move to "plan B".
The "bundled subscriptions" need to be negotiated in both directions.
That means something like:
INVITE must contain:
- these are the events I am willing to send
- these are the events I desire to receive
response must contain:
- these are the events I will send (subset from invite)
- these are the events you should send (subset from invite)
Note that probably excludes events that take various combinations of
parameters, and subscriptions that require filters. (Though both of
these could probably be required by adding enough complexity.)
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
