Brian Stucker wrote:
You forgot about supported.
So for example, DTMF: Using this model of SIP extension, we
might define a new "DTMF" method. It would look just like
DTMF-over-INFO, except the name of the method would be DTMF.
It clearly resolves the INFO-context question, because now we
KNOW we're getting dialog- related DTMF over it, and we know
what to do with it. We know what we can transport in
DTMF-requests, because the RFC that defines the DTMF
extension method will also define exactly what payload format to use.
INVITE
Supported: foo
Allow: INFO
Accept: application/foo
200 OK
Supported: foo
Allow: INFO
Accept: application/foo
...
INFO
Content-Type: application/foo
[DTMF]
Where is this broken?
This can work if there is an RFC defining the foo option that specifies
that when both parties support foo then:
- the UAC may use INFO to send information using
Content-Type application/foo and Content-Disposition: (TBD)
- the circumstances triggering the UAC to send are ...
- the expected actions of the UAS upon receiving are ...
Because this uses an option, and a new option can only be defined via an
RFC, this technique is only available (legally) when an RFC will be
approved. (Of course people have been known to invent new options
without an RFC, but that is non-conforming usage.)
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
