Yes, but Dean is asking if we even need the concept of a recv/send/sendrecv. You would need to specify recv/send/sendrecv for each info-event-package. The question is: is it necessary for a general info-event-package negotiation mechanism?
-hadriel > -----Original Message----- > From: Francois Audet [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 17, 2007 11:18 AM > To: Hadriel Kaplan; Dean Willis; Paul Kyzivat > Cc: sip; Brian Stucker; Christer Holmberg > Subject: RE: [Sip] INFO > > 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
