Hi John, >>"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?
It is probably true that a SIP phone type of UAS would not implement a new configurable parameter for this. However, the UAS could be a "network entity", e.g. an application server, or a B2BUA, and in such cases the operator may have a configurable parameter. So, I think we should allow it. >>"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 :) >>"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. Yes, that should be clarified. >Also, if there is no compulsion to store these header fields, why make it mandatory to transmit >them if they have been stored? I was requested to add text about the possibility to store the header fields and included them in the response. I see no harm in doing so, since storing the parameters is optional anyway. Regards, Christer > 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
