Wow, this has been a heartily discussed topic.
I'd like to recap some points I think we have a mostly-working
consensus on:
1) INFO is underspecified and lacks a satisfactory negotiation
mechanism for usages thereof.
2) We need more than just content-type and content-disposition to
describe and negotiate usages of INFO. The event package nomenclature
seems to satisfy this need.
3) SIP Events (RFC 3265) could functionally replace all uses of INFO,
but there are reasons (primarily relating to overhead and complexity)
for the fact that we continue to see deployments using INFO.
4) The situation relating to INFO and the angst and confusion
stemming from it are sufficiently motivating for us to at least
heartily debate the topic, and presumably motivating enough for us to
actually tackle a solution at the working group level.
5) We do NOT believe that just deprecating INFO will make the problem
go away.
6) We believe that something that allows events to be negotiated as
part of an INVITE-initiated dialog usage would satisfy the majority
of the requirements.
Some less-consensed items include:
7) Use of NOTIFY, INFO, or some other method for the invite-dialog
event method. We have a majority position that is best described as
"anything but NOTIFY", and the remainder is roughly split on INFO vs
something else.
8) Do we use the same registry and review process for invite-dialog
events as for subscribe-dialog events? This seems to be in part
predicated on whether any events will occur in both types of dialogs.
The emerging consensus seems to be that at least some events could be
used in either dialog type, and that therefore a single registry and
process is needed. However, we probably need to add a column to the
registry for the dialog-type.
9) While we agree that we need to negotiate directionality of event
flow (being able to send an event is not the same as being able to
receive it), we're up in the air on mechanism. We have proposals for
either replacing Allow-Events (in INVITE request) with two new header
fields such as "Send-Events" and "Receive-Events", or of extending
each event-package name with a sub-parameter indicating
directionality similar to those used in SDP (send, recv, sendrecv or
the like). While functionally equivalent, the first fits into our
existing IANA registries more readily and is therefore easier to
document.
These leads to a concrete proposal:
I propose we develop a new RFC that extends RFC 3265 and obsoletes
RFC 2976.
This RFC will document use of event bodies in INFO messages exchanged
in dialog usages established by SIP INVITE transactions. This will
include definition of the "Send-Events" and "Recv-Events" header
fields, use of those header fields in INVITE transactions to provide
an offer/answer exchange, definition and use of a new option tag for
this extension, and the needed changes to the registry established by
RFC 3265.
There may then be a need for a subsequent RFC or RFCs to extend RFC
3398 (ISUP) and RFC 4498 (QSIG) for consistency with the new model of
INFO.
So, how does this sound to people?
--
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
