Hi, >>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)
Maybe we could re-use the SDP direction attributes (sendrecv, sendonly, recvonly) for this? 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
