Robert Sparks wrote:
7) Section 7: "A UAC that receives a 199 response for an early dialog
MUST NOT
send any further requests on that dialog...". Can you point to any
list discussion
around this requirement? I think there's some danger to consider
there. At the
very least we need to make this statement multiple-usage safe.
This is a very good catch. This needs to be aligned with dialogusage. If
the 199 contained the final response that triggered it, then that final
response could be used to determine the impact on the dialog or dialog
usage or just the transaction. But if the 199 doesn't contain the final
response, then this is a problem.
12) The open issue in section 10 (can we get a proxy involved in sending
its own
199 reliably) is a big part of the confusion I pointed to at the
beginning of
these comments. This is the part of the draft that I expected
needing face time
in Dublin, but maybe we can make enough progress on it in the
hallway.
I don't think there's any way to allow it, and what we'll need
instead is text
more strongly recommending the endpoints do this themselves and
restrict
any proxy genesis of 199s to the unreliable case (and explain
more that this
is just a transitionary optimization - we _really_ want the
endpoints doing this
work if anything's going to be doing it at all.
If the "proxy" wants to send a reliable 199, then I think it needs to do
so on its own dialog. But that makes no sense. Having the proxy attempt
to send the reliable response on the dialog belonging to the UAS is
*insane*.
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
