> We all agree on what the text says for the INVITE, UPDATE, > and ACK methods, as well as the 101-299 (stuff counts) and > 300-699 (something is broken, so it does not matter) > response codes.
In case it matters, ACK can't be authenticated and introduces more race conditions. RFC 3261 did not define Supported and Allow to be optional within an ACK. I mention it in case there were similar race condition and authentication concerns associated with using ACK to indicate/update what is supported and allowed. > It is probably sensible to exclude 100 from Recv-Info processing. > Work for you? Yes. > What about PRACK/PRACK 2xx? My vote is they count like everything > else. What about you? Because of race conditions, I prefer the header not be allowed. However my concerns would be partially alleviated if not required to include Recv-Info to avoid disabling support. It has been awhile since I read RFC 3262 in depth. If UAS sends INVITE 2xx while awaiting PRACK, should it return PRACK 481 or PRACK 200 upon receipt of PRACK? If acceptable to return PRACK 200 during the race condition, should the PRACK's Recv-Info be ignored if received before or after ACK? If it returns PRACK 200 and UAS receives PRACK 200 after INVITE 200, should the UAC ignore PRACK 200's Recv-Info? > Likewise, what about REFER/REFER 2xx? My vote here is INFO packages > would be nonsensical during a refer, but perhaps you have a use case? > If so, they work like everything else. I have no preference, especially if not required to include Recv-Info to avoid disabling support. > The current text is pretty adamant that a missing Recv-Info means you > do not (want to) understand Info Packages. If you start with a Recv- > Info and you later drop the Recv-Info header, all bets are off. Are > you happy with that? No. It requires uselessly adding the header everywhere. It increases race condition complications. It shouldn't be more mandatory everywhere than Supported and Allow. I'm not opposed to making it mandatory within INVITE, re-INVITE, and their 2xx; it should at least be optional within UPDATE. Concerning other locations, I'm not opposed to it being optional although it introduces more potential for race conditions. > Since we do have Recv-Info: nil, we do have the opportunity to > say we only change the Info Package set if a Recv-Info header > is present. What do you think? I like the suggested modification. If retarget to a device not supporting the RFC, the modification potentially raises the need for a Supported option-tag unless Recv-Info remains mandatory (to avoid disabling) within a few locations. However B2BUAs can still work around the issue if the working group doesn't want to define an option-tag for the RFC. > Likewise, if I have missed something, please bring it up now, NOT at > the meeting. Recall this draft has finished WGLC. What was the outcome of INFO 489 response MUST trigger release of call discussion? Thanks, Brett _______________________________________________ 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
