Christer,
"If the received initial request contains an 199 option tag, the UAS
SHOULD NOT send a 199 response for a dialog on which it intends to
send a final response, unless it e.g. has been configured to do so
due to lack of 199 support by forking proxies or other intermediate
SIP entities."
I doubt that a UAS would implement a new configurable parameter just so
that it can reduce resource consumption at the UAC when the forking
proxy has not bothered to implement 199. It is far easier for the UAS
never to send 199. So is it really worth specifying this option?
"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.
"If the forking proxy has stored the Contact and Record-Route headers
for the early dialogs, it SHALL insert the headers in the 199
responses."
Which Contact and Record-Route header fields? Presumably the ones
received from the UAS (as opposed to the UAC), but it doesn't make this
clear. Also, if there is no compulsion to store these header fields, why
make it mandatory to transmit them if they have been stored?
John
________________________________
From: [email protected] [mailto:[email protected]] On
Behalf Of Christer Holmberg
Sent: 07 January 2009 08:49
To: [email protected]
Subject: [Sip] New version (-04) of draft-ietf-sip-199
Hi,
Based on comments and discussions, I've submitted a new version
of the 199 draft.
The currently remaining to-do is to add text to the security
chapter.
The draft can also be found at:
http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-04.txt
<http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-04.txt>
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