As a swag for how to encode this in actual headers, how about:
INVITE ...
Exchange-Events: dtmf;sendrecv, foo;sendonly;
bar;recvonly; xyzzy;sendrecv
200 OK
Exchange-Events: dtmf;recvonly, foo;recvonly;
bar:sendonly; xyzzy:inactive
Each event type named in Exchange-Events in the INVITE is a candidate
for use with the directionality specified by the direction parameter.
Event types not listed implicitly have a direction of "inactive". Event
types listed without a direction are implicitly sendrecv.
The Exchange-Events in the response defines which event types will
actually be exchanged, and the direction(s) they will be sent. Default
directions are the same as above. The valid directions in the response
are constrained by what was in the request in the same way as in sdp.
One agreed upon, NOTIFY may be sent in the agreed upon direction(s)
within the INVITE dialog usage. Whether an initial NOTIFY is required
will be determined on a per-event-package basis. (Its not needed to
establish the dialog, so its a matter if it is semantically needed in
the context of the event type.)
Just as there are INVITEs that don't offer SDP (because they don't know
what to offer) there is a need for INVITEs that don't offer events. An
INVITE that contains no Exchange-Events header is not offering any. In
that case the offer of events is in a reliable response and the final
answer about what events will be used is in the ACK or PRACK. (To
indicate that you don't desire to exchange any events, include a
Exchange-Events header with no events listed.)
There is no separate subscription or timer. The dialog usage is
refreshed by INVITE or UPDATE in the conventional manner. Events to be
exchanged are renegotiated from scratch with every reINVITE or UPDATE.
If an event type takes parameters, they can be included in
Exchange-Events. That can work in some simple cases, but not in complex
cases. I think event types that need complex parameters will be
problematic in this usage. (Note that the kpml package only requires
parameters to identify the dialog. In this usage those won't be needed.)
There is a problem if the event type may (or must) use a body in the
subscribe. The kpml package falls into this category. :-(
The body could simply be included in the message carrying the
Exchange-Events header. But that potentially means a bunch of body parts
with the recipient having the problem of deciding how each part should
be matched to a particular event type. That is more or less the same
problem we are trying to solve here, so its not good. Also, it would
seem that every time you send a reinvite or update you might have to
send these again.
One alternative is simply to say that this mechanism cannot be used with
event packages that require a subscribe body. That seems to exclude the
use of KPML. :-(
Paul
Paul Kyzivat wrote:
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
_______________________________________________
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
