Christer,
I finally got around to this. A few comments:
Section 1:
When SIP entities upstream
receive the 2xx final response they will automatically terminate
other associated outstanding early dialogs.
This isn't always wise. At this point it is still possible to receive
additional 2xx responses. Discarding the early dialog is probably fine
if subsequent 2xx responses with be dealt with by sending BYE. Retaining
the early dialog isn't useful in that case. But if the UAC is planning
to accept an additional 2xx response and retain the dialog rather than
terminate it, then it should not discard the early dialog upon receipt
of the first 2xx.
(Note that sending cancel upon receipt of a 2xx is MUST in 3261, but it
is overridden by a 'Request-Disposition: no-cancel' specified in RFC
3841. Terminating the early dialog at the UAC is also a MUST, but seems
like it is probably an error.)
Section 4:
You give examples of kinds of resources that may be freed upon receipt
of the 199. But you also hint at a problem:
If the client is able to associate the 199 response with a specific
media stream,
In many cases it may be hard/impossible to accomplish this. Can you give
some plausible examples of cases when this will be possible?
I don't understand the following:
The UAC MAY use additional information (for example the final
response which triggered the 199 response) received in the 199
response when initiating new sessions, if it is possible to avoid the
new session initation request to be rejected.
I can't parse it into anything meaningful.
Section 5: When would it be advantageous for the UAS to send a 199?
Section 6:
This has MUST strength language. But of course not all proxies will
implement this draft if/when it becomes an RFC. It it expected that this
is to be an independent RFC to which support may be claimed?
Section 8:
OPEN ISSUE: We need to discuss whether the To tag in the 199
identifies the dialog that has been terminated, and/or if some
additional information element (e.g. SIP header) can be used, which
would allow to indicate the termination of multiple dialogs in a
single 199 response.
My preference is to use the To-tag, so that normal dialog matching rules
will apply. We don't need more irregularities to complicate sip stacks.
OPEN ISSUE: We need to discuss whether, in addition to the dialog
identifier, some additional information (e.g. the non-2xx final
response which triggered the 199 response) should be provided in the
199 response.
I think it would be useful to at least acknowledge that a sipfrag can be
carried in the 199, in a similar way to is carried in a refer event
package notification. Would probably be good to state that it SHOULD NOT
be included unless there was an Accept header mentioning the sipfrag
content type in the request.
Section 9:
A 199 Early Dialog Terminated provisional response MUST NOT contain a
new SDP offer/answer message body, but the sender of the response MAY
insert a copy of a previously sent offer/answer message body as
otherwise allowed by the offer/answer rules for a provisional
response.
A forking proxy or a UAS MUST NOT trigger and send a 199 Early Dialog
Terminated provisional response reliably in a situation where a
reliable provisional response is required to contain an SDP offer/
answer message body, according to [RFC3262] and [RFC3264].
These two paragraphs seem to be slightly at odds with one another,
regarding the sending of an answer in a reliable 199. This can be fixed
by changing the 2nd paragraph to only mention "offer", not "answer".
Section 10:
OPEN ISSUE: We need to discuss whether a proxy should send 199
reliably at all, since the proxy would have to terminate the
associated PRACK, and support the logic associated with 100rel. If
not sent, how would required 100rel affect the usage of 199?
IMO it is a bad idea for a proxy to send a reliable 199. The problem is
that you aren't sending the 199 unless there was already an early
dialog. If there was, the proxy is not the second party in that dialog.
The PRACK will be sent to the peer in the dialog, not the proxy. The
proxy has no business terminating and responding to it. Yet the UAS
won't be expecting it.
So I think it would only be possible to send a reliable 199 as part of
some new dialog terminated by the proxy. But that then means the To-tag
can't be used to indicate which dialog is being terminated. It just
keeps getting more and more complicated.
And there really isn't any great value in sending this reliably. So
don't do it.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.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
