> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 17 October 2007 17:17 > To: Sumit Garg > Cc: sip; Francois Audet; Brian Stucker; Dean Willis; Christer Holmberg > Subject: Re: [Sip] INFO > > > > Sumit Garg wrote: > > Another approach to avoid unnecessarily long bodies: (this > would be more > > on lines of offer-answer) > > INVITE- these are events A desires to receive. > > > > 1st reliable response (provisional/200OK) from B: > > - this is the subset of events (from the offer from > A) which can > > be provided by B. > > - this is the set of events B desires from A. > > > > ACK/PRACK: > > - this is the subset of events (from the offer from > B) which can > > be provided by A. > > That would work. I find it slightly more attractive than the > sendrecv/sendonly/recvonly/inactive approach, though both are roughly > equivalent in power. [JRE] A down side is that for mid-dialog changes it requires re-INVITE, rather than UPDATE.
John > > > Wouldn't the best approach be to supersede the INFO RFC > with one which > > takes care of issues, i.e. with these additional headers. > > We can't get people to change the old implementations, but > at least the > > for new usages if the additional work required is a smaller > delta (from > > base INFO, as compared to having to implement > SUBSCRIBE/NOTIFY), they > > might be more amenable to use the new EVENT based INFO mechanism. > > Frankly, I think what we are discussing would be better applied using > NOTIFY in the INVITE dialog. We would then be devising a new means to > negotiate event packages that will share the invite dialog, but using > the same NOTIFY messages to carry the data, not INFO. > > Paul > > > -Sumit > > > > "The reasonable man adapts himself to the world; the > unreasonable one > > persists in trying to adapt the world to himself. Therefore > all progress > > depends on the unreasonable man." > > -- George Bernard Shaw > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, October 17, 2007 9:24 AM > > To: Christer Holmberg > > Cc: sip; Francois Audet; Brian Stucker; Dean Willis > > Subject: Re: [Sip] INFO > > > > > > > > Christer Holmberg wrote: > >> Hi, > >> > >>>>> 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? > >>> Are you serious? Or have you been smoking something? :-) > >> Sometimes I think that would help in these discussions :) > >> > >>> Certainly you can use the SDP direction attributes if you want to > >>> establish media sessions for this event signaling. > >>> But AFAIK the point here is to negotiate the use of > signaling in the > >>> sip session itself. > >> I guess I should have been more clear. I didn't mean that we start > >> using SDP for this, but that we could use something SIMILAR to the > >> direction attributes - but in the form of some SIP header > parameters. > > > > Oh - thats not quite so crazy. > > > > Yes, I suppose something like that could be done. But given how much > > confusion that seems to have caused with SDP, I would > certainly think > > twice before using it again. > > > > Note that this will need to be more than a one-time negotiation. Its > > possible that the agreement will need to be renegotiated in > mid-call. > > (This comes up at least in 3pcc scenarios, where a device > in the middle > > is performing a transfer without the knowledge of the other side.) > > > > 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 > > > > > _______________________________________________ > 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 > _______________________________________________ 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
