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?)
Don't know... Does the dialogusage spec talk about early dialogs?
>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.
I agree, and I can put some text about that.
Because, even if the 199 response did affect the whole dialog, the UAC should
find out about it once the forking proxy sends a final response.
Regards,
Christer
_______________________________________________
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
