> > - "The INFO message MUST NOT change the state of the SIP > dialog. The > > only exception to this rule is for specific failure responses as > > documented in RFC 5057 [RFC5057], which may cause the > INVITE dialog > > to terminate." > > This jogs another question in my mind. Is it permissible to > pass Send-Info / Recv-Info headers in an INFO? If so, then > IMO those change the state of the dialog.
The answer is currently no. INVITE and 1xx,2xx responses to INVITE, OPTIONS and 2xx responses to OPTIONS. REG was still under discussion although it is the draft. Keith > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Paul Kyzivat > Sent: Monday, November 10, 2008 4:10 AM > To: Elwell, John > Cc: SIP IETF > Subject: Re: [Sip] Comments on sip-info-events-01 > > Some followups to John's comments. I've trimmed down to > relevant stuff. > > Thanks, > Paul > > Elwell, John wrote: > > > - I think I suggested once before that we should not treat > > Send-Info/Recv-Info exchanges like offer/answer, but should > just have > > a simple rule that says that a UA can send these header > fields at any > > time and they supersede any sent previously. A UA MUST not > send INFO > > unless the package has been identified in the last > Send-Info sent and > > the last Recv-Info received. A UA MUST (SHOULD?) discard a received > > INFO unless the package has been identified in the last Recv-Info > > sent, and MUST be prepared to receive an INFO for a package > as soon as > > it has sent a Recv-Info identifying that package. These > header fields > > MAY be included in an INVITE request, in a dialog-forming > response to > > an INVITE request, or in any other request or response in > the context > > of an early or full INVITE-initiated dialog. This would be a lot > > simpler. Is there any reason it would not work? I am not certain I > > have enumerated all the rules here, but I doubt if very much more > > would need to be said normatively. > > I think this will work as long as he contents of these > headers on one side are not coupled with those on the other > side. IOW, I should be able to mention a package in Recv-Info > even if it wasn't mentioned by the other side, and visa versa. > > But can somebody remind me why we need Send-Info at all? > > However in any case we must accept that there is a race > condition, when an INFO is in flight at the same time as a > Recv-Info in the other direction that forbids sending it. I > think that is fine - it will just be rejected, and that > should not be considered a serious error. > > > "If the UAS receives an INFO request with a Info-Package the UAC > > advertised with a Send-Info in the last dialog state update" > > It was not clear to me that every dialog state update MUST contain > > Send-Info/Recv-Info. In other words, if I send an UPDATE request > > without these header fields, e.g., for session timer refresh, does > > this cancel any previous negotiation of Info Packages? I > would prefer > > that it did not, that it simply left things unchanged. > > We need to be careful here, to prevent breaking 3pcc. If a > transfer is done via 3pcc, how can we ensure that the desires > of the unchanged party are made known to the transfer target? > This could be ensured that the Send-Info/Recv-Info headers > are always sent when an offer or answer is sent. > > > - "If a server receives an INFO request with a body it > understands, but > > it has no Info-Package header, the UAS MAY render the body." > > This is the first mention of "render". In fact there is > nothing to say > > that a UAS must/should/may render a body when an INFO > request is not > > in error, so it seems odd to talk about rendering when there is an > > apparent error in the INFO request. Is "rendering" necessarily the > > appropriate thing to do with a received and valid INFO > request. Should > > we instead say "...the UAS MAY make use of the body"? > > Yeah, "render" could be quite confusing. Perhaps "process"? > > > - "The UAS MUST send a 481 Call Leg/Transaction Does Not > Exist message > > if the INFO request does not match any existing dialog." > > Shouldn't this say "...does not match any INVITE-initiated dialog"? > > INVITE-dialog-usage? > > (I could have a dialog that was initiated with an INVITE, > then piggybacked with a SUBSCRIBE, then BYE to the INVITE, > but subscription remains. That is still an INVITE-initiated > dialog, but INFO isn't valid.) > > > - "The INFO message MUST NOT change the state of the SIP > dialog. The > > only exception to this rule is for specific failure responses as > > documented in RFC 5057 [RFC5057], which may cause the > INVITE dialog > > to terminate." > > This jogs another question in my mind. Is it permissible to > pass Send-Info / Recv-Info headers in an INFO? If so, then > IMO those change the state of the dialog. > > > - "A UAC, the sender of the OPTIONS request, MAY include > Send-Info and > > Recv-Info headers, populated appropriately for the > packages the UAC > > supports. The UAS MAY include its set of Send-Info and Recv-Info > > packages. The UAS and UAC MUST NOT consider the OPTIONS > request to > > be part of a capabilities negotiation. The OPTIONS > request is purely > > a probe." > > The semantics of these header fields in an INVITE request > or another > > message in an INVITE-initiated dialog means I am prepared to > > send/receive these packages in the context of this dialog. However, > > for OPTIONS there is no dialog. So what exactly are the > semantics of > > these header fields in OPTIONS request? Presumably it just means I > > support these packages and may be prepared to send/receive > them in the > > context of an INVITE-initiated dialog. This should be clarified. > > I agree. (I have similar problems with everything in an OPTIONS.) > > > - In 5.1, Why is Contact allowed in an INFO request but not > in a 2xx > > response to INFO? Since INFO is not allowed to change > dialog state, it > > cannot change target URIs, so what would be the meaning of > Contact in > > an INFO request. I think we should align with BYE and not allow > > Contact in INFO. > > Agree. > > > - "For the purposes of matching Info Package types > indicated in Send- > > Info or Recv-Info with those in the Info-Package header > field value, > > one compares the Info-package-name portion of the > Info-package-type > > portion of the "Info-Package" header byte-by-byte with > that of the > > same in the "Send-Info" or "Recv-Info" header values." > > Presumably comparison is case-sensitive. Should we state this? > > By default I would assume case-insensitive behavior. That is > the norm for most things. Is there a reason to be case sensitive here? > > _______________________________________________ > 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 > _______________________________________________ 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
