Hi John, 

>>>>"When a forking proxy receives a non-2xx final response which 
>>>>terminates one or more (if forking has occured downstream a final 
>>>>response received by the forking proxy MAY terminate multiple early 
>>>>dialogs), and the proxy does not intend to forward the final 
>>>>response immedialetly (due to the rules for a forking proxy),
>>>>and the UAC has indicated support of the 199 response code, the
proxy 
>>>>SHOULD generate and send a 199 response upstream for the early
dialog
>>>>on which the non-2xx final response was received, unless the proxy
has previously 
>>>>recieved and forwarded a 199 response for the dialog."
>>>
>>>Wow! We really must shorten this sentence. In particular I don't like

>>>including a second normative sentence in parentheses within the main 
>>>sentence.
>> 
>>I can try to think of more simple wording. 
>> 
>>And, text suggestions are of course always welcome :)
>> 
>How about:
>"When a forking proxy receives a non-2xx final response that terminates
one or more early dialogs, if the proxy does not intend to forward the
final response immediately (in accordance with rules for a 
>forking proxy) and the UAC has indicated support for the 199 response
code, the proxy SHOULD generate and send a 199 response upstream for
each early dialog terminated on the downstream side by the 
>non-2xx final response, except for any early dialog for which the proxy
has previously received and forwarded a 199 response. Note that if
forking has also occurred downstream of the forking proxy, a 
>final response received by the forking proxy can terminate multiple
early dialogs."
>
>I have removed the normative statement that was in parentheses and
created a separate sentence at the end. However, I believe it does not
need to be normative - it is just a statement of something that 
>arises because of the normative provisions of RFC 3261.
>
>I believe the proxy should send a 199 response on EACH affected early
dialog (unless 199 already sent). This too is reflected in my proposed
rewording.

That is covered in the existing text:

"If the forking proxy generates a 199 response, and if the forking proxy
is able to
identify additional early dialogs which are terminated by the same
non-2xx final response, it MUST also generate and send a 199 response
upstream for each of those early dialogs, except for any dialog on
which the proxy has previously received and forwarded a 199 response."

I don't mind working with your proposal, but I think it important to
keep the "IF the forking proxy is able to identify additional early
dialogs" part, because the forking proxy may not be able to associate
other early dialogs with the non-2xx response.

One proposal would be the following:

"When a forking proxy receives a non-2xx final response that terminates
one or more early dialogs, if the proxy does not intend to forward the
final response immediately (in accordance with rules for a 
forking proxy) and the UAC has indicated support for the 199 response
code, the proxy SHOULD generate and send a 199 response upstream for
each early dialog terminated (if the forking proxy is able to identify
additional early dialogs that are terminated by the non-2xx final
response) on the downstream side by the non-2xx final response, except
for any early dialog for which the proxy has previously received and
forwarded a 199 response. Note that if forking has also occurred
downstream of the forking proxy, a final response received by the
forking proxy can terminate multiple early dialogs. Based on
implementation policy, the proxy MAY wait before sending the 199
response, e.g. if the proxy expects to receive a 2xx final response on
another dialog shortly after it received the non-2xx final response
which triggered the 199 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

Reply via email to