> -----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
