I think the recv/send/sendrecv approach that Christer was proposing addresses this.
> -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 17, 2007 07:40 > To: Dean Willis; Paul Kyzivat > Cc: sip; Audet, Francois (SC100:3055); Stucker, Brian > (RICH1:AR00); Christer Holmberg > Subject: RE: [Sip] INFO > > > > -----Original Message----- > > From: Dean Willis [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, October 16, 2007 10:05 PM > > To: Paul Kyzivat > > Cc: sip; Francois Audet; Brian Stucker; Christer Holmberg > > Subject: Re: [Sip] INFO > > > > > > On Oct 16, 2007, at 6:08 PM, Paul Kyzivat wrote: > > > > > 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 > > > > Do we need that first line ? Or do we just need "These are > the events > > I'm willing to receive. If I get them, great. If I don't, well, I > > don't care, I'll assume that sending them wasn't important to you." > > But that's not always the case with dtmf. If a softphone > makes a call, would the softphone always care to receive > DTMF? Not all of them would. But they would want to tell > the far-end they can _send_ DTMF. Not that I think this > means we need a send/receive distinction - I think just a "I > support dtmf-info" semantic is good enough for dtmf. > > > > Is there a use case for turning this into a full > bidirectional offer- > > answer? > > I guess the question is if it matters that a UA which can > only send event foo but can't do anything useful receiving > foo, could be sent foo anyway. For example, suppose we > created an event-package for a jpeg picture, for remote-party > call display. If a hard-phone has no LCD to display a > picture, but has a stored jpeg to give to the far-end, would > it matter if it can't say "I can send a jpeg but don't want > to receive one"? Obviously it could just accept a received > one (ie, 200 ok the INFO) and discard the jpeg. But is that > the right thing to do? I dunno. We could just leave the > concept up to specific info-event-package definitions to > handle - i.e., make an event-package define send vs. receive > event-packages pairs if it cares about it. > > -hadriel > _______________________________________________ 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
