Hadriel Kaplan wrote:
Howdy,
Inline comments, but also: this seems like going down the road of complexity
again. One of the reasons I think people use INFO-dtmf instead of KPML is it's
so darn simple/easy. If we want people to change their implementations to
support negotiation and explicit content context indication, it should be as
trivial as possible, IMHO. No bells, no whistles.
SIP is not simple. If you have mastered doing the rest of sip then this
is not a burden. IMO people are more concerned with extra messages and
extra state than they are with making it extra simple.
I do agree that things should be as simple as possible - but no simpler.
Too often things are made "simple" at the expense of being inadequate
for the real job. INFO is in fact an example of this.
More below.
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
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.)
Why do this? What use case is there for not saying what you can do in the
Invite? Offer-less Invites cause enough problems. We shouldn't repeat them.
I know of lots of cases that can loosely be categorized as 3pcc where
there is a B2BUA in the middle that initiates invites. It needs to learn
the capabilities of one UA and then offer them to another. Because it is
simply going to act as a signaling relay it doesn't have any preferences
of its own about these things.
In general I have found that 3pcc is a good source of requirements that
are otherwise often overlooked. Better to capture them up front than
discover them later.
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.
Ya that's bad. If someone wants to define an info-event that needs such
things, they can define it to exchange it in an INFO when they do.
I'm hoping we don't have to define a whole new set of event packages.
That is one of the reasons I would prefer to use an
in-invite-dialog-usage NOTIFY than INFO for this. Ideally already
existing event packages can then be used in this new way.
Maybe some of them will need some slight enhancement, but that would be
better than having to define a whole new and parallel set.
Not only will that speed things up in the standardization process, but
also it will simplify implementation and improve chances of support.
Paul
_______________________________________________
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
