We don't need all these nuances - just a few. It isn't important to say
"I could deal with X if you sent it but I don't want you to send it."
There are two paradigms already used in sip, and discussed here, and
either could be used:
1) X tells Y: I would like you to send A,B,C
Y tells X: I will send you B,C; I would like you to send B,C,D,E
X tells Y: Please send B,E
2) X tells Y: I can send A,B,C; want to receive B,C,D,E
Y tells X: I will send you B,C; Please send me B,E
The use of the directionality attributes is an encoding of (2):
2b) X tells Y: sendonly(A), sendrecv(B,C), recvonly(D,E)
Y tells X: inactive(A,D), sendrecv(B), sendonly(C), recvonly(E)
Paul
Dean Willis wrote:
On Oct 17, 2007, at 9:39 AM, Hadriel Kaplan wrote:
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.
I think we need two different approaches here.
There is a big difference between "I could deal with X should you want
to send it" and "I NEED you to send me X" or "I want to know if you
intend to send me X".
The first is a simple declarative, along the lines of what we do with
Supported and Allow. The latter two are more directive, something like
what we do with a Require.
Otherwise said, there's a difference between "I support" and "I will
use" or "Will you use?".
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.
I suspect that things that need two way send-receive negotiation need to
use full subscriptions. Actually, they may need to use full
subscriptions in each direction.
But let's play with this negotiation a minute.
Suppose instead of having a single header field for "all the
events-in-invite-dialogs we know about", we have two header fields: one
for events we are willing to receive, and another for events we are
offering to send. Those two sets might not match for a given device, but
they would need to reduce down to pairwise matches after the
offer-answer phase, so that neither end would be intending to send
something the other hadn't indicated a willingness to receive.
So, for example. Alice might INVITE Gateway, saying "I understand keymap
and image-display events and may send you keypad events", and gateway
might answer in the 200 OK "I understand keypad events and may send you
keymap events" (note that gateway is NOT offering to send image-display
events) . Alice might then echo (in ACK) "We agree that I may send you
keypad events and that you may send me keymap events".
Or, as you suggested, we could define directional event packages and use
a single header field.
Alice might INVITE Gateway, saying "I'm offering to use send-keypad and
receive-keymap and receive-image-display events". Gateway responds with
"I will support receive-keypad and send-keymap events" (note it didn't
include send-image-display). Alice then ACKS with "I understand I will
be doing send-keypad and receive-keymap".
The two are functionally equivalent, I think we just have a syntax
question. I suspect that the two-header approach is easier to parse.
But a broader question is lurking here . . .
How is this not just an example of a more general feature or capability
negotiation mechanism? If instead of "event packages" we talk about
"features", where a feature might be "send event X", "receive event X",
or perhaps something broader like "transition to a DOOM game"? Could we
use it to discover a peers screen resolution, keyboard layout, or access
network bandwidth? Could we do the same media-channel O/A that we do in
SDP? I believe the answer is "yes", but it requires a registry process
for each of the "features", much as we currently have a registry process
for event packages. Do we want to go in this direction? If not, where do
we draw the line? And just exactly how does this relate to RFC 3840/3841
preferences and capabilities negotiation (which, I might add, don't
really work in a proxyless world).
--
Dean
_______________________________________________
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
