Dean,
Nice summary.
I generally agree with what you have written.
My major concern is with the negotiation mechanism. In particular I
think it needs to be done as a two-way handshake, not three way. A three
way negotiation will not work well with 3pcc.
Thanks,
Paul
Dean Willis wrote:
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
_______________________________________________
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
