Hi, >I would still propose to replace : > >"When a proxy receives a 199 response, it MUST process the response as >any other non-100 provisional responses...." > >with > >"When a proxy receives a 199 response on an early dialog, it MUST process the response as any other non-100 provisional responses.... > >If a proxy receives a 199 response out of dialog, it MUST drop the response." > >You are writing a RFC here and everything must be spelt out. > >This is not simply an implementation issue and it is >contradictory to state on one hand that the proxy "MUST >process the response as any other non-100 provisional >responses", and on the other hand thinking that it is quite >clear that a proxy which support 199 would not create a new dialog. >Creating a new dialog is the normal behaviour of receiving a >non-100 provisional response with a new To tag. A >199-unaware proxy will certainly do that.
I would then propose that we say that a proxy SHOULD drop unreliable 199 responses which are sent out-of-dialog. If the 199 response is sent reliably, I don't think we can drop it. >-------------- > >And to your reply > >"When the forking proxy forwards a final response it >terminates all early dialogs." > >I do not agree that when the forking proxy forwards a final >response it terminates all early dialogs, as we are talking >about INVITE transaction here. > >RFC3261/16.7 bullet 10: > >If the forwarded response was a final response, the >proxy MUST generate a CANCEL request for all pending client transactions >associated with this response context.... > >The requirement to CANCEL pending client transactions upon >forwarding a final response does not guarantee that >an endpoint will not receive multiple 200 (OK) responses to an >INVITE. 200 (OK) responses on more than one branch may be >generated before the CANCEL requests can be sent and processed. Yes. It's a race condition. >and RFC3261/16.7 bullet 5: > >This step, combined with the next, ensures that a >stateful proxy will forward exactly one final response to a >non-INVITE request, and either exactly one non-2xx [final] response or >one or more 2xx responses to an INVITE request. > >and RFC3261/13.2.2.4: > >The UAC core considers the INVITE transaction completed >64*T1 seconds after the reception of the first 2xx response. At this >point all the early dialogs that have not transitioned to established dialogs are >terminated. Once the INVITE transaction is considered completed by >the UAC core, no more new 2xx responses are expected to arrive. Implementations will normally terminate all other early dialogs when the first 2xx is recevied. Then, if additional 2xx response (on other dialogs) are received, implementations will normally send ACK+BYE for them. So, yes, the INVITE transaction is still alive, but the early dialogs are normally terminated. >The 199 mechanism will only indicate early dialogs that are >terminated before the first 2xx. If the first 2xx arrives >very early, immediately after many early dialogs are created, >all subsequent non-2xx final responses for those early >dialogs cannot be conveyed to the UAC with 199. Even if the >first confirmed 2xx dialog is terminated with BYE, the UAC >still could expect further 2xx responses to arrive on early >dialogs within 64*T1 seconds after the reception of the first >2xx response. I doubt that a UAC implementation which recieves the first 200 OK, and then send BYE for it, will sit and wait for additional 2xx responses to arrive. The UAC will consider the call to be terminated, and free all resources for it. Otherwise, if resources are limited, the UAC may not be able to make a new call until 64*T1 seconds... Also, as the text in 16.7 says, once a final response has been forwarded, the forking proxy sends a CANCEL for all other forked legs. So, additonal 2xx responses will only reach the UAC if some an UAS sent a 2xx response before it received the CANCEL from the forking proxy. But, in any case, I can add a bullet with a condition that 199 is only sent if a final response has yet not been sent. 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
