Christer Holmberg wrote:
Hi,
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.
I forgot to bring this issue up in Dublin. Sorry for that.
First, we need to remember that the UAS may terminate every dialogusage
when sending the final response (depending on what final response is
sent), without the UAC knowing it. And, due to the forking rules, the
final response which is sent to the UAC may not even be the same which
was sent by the UAS, if a final response from another UAS is chosen as
the "best".
Second, we need to remember that this only affects early-dialogusages.
If needed, I guess we could include the final response which triggered
the 199, but we could also simply say that if the UAC does not know to
which dialogusage (if there are many) the 199 applies, it should not do
anything which may affect other usages for the same early dialog.
The establishment of multiple early dialog usages is a pretty strange
thing. Do we know of any use cases for this? (E.g. an in-dialog REFER on
an early INVITE. Is that legal?)
Assuming it can arise, then I agree it is reasonable to treat the 199 as
affecting only its dialog usage unless there is info with it (such as
the actual final response code) that gives evidence that the whole
dialog is gone.
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
