> B side client is attempting to refresh the session using > re-INVITE without SDP. > A acknowledges the refresh with 200OK without SDP
B is not attempting to refresh the session (although it can occur at the same time). If it was, the re-INVITE should contain an SDP. A is non-compliant since it did not generate an offer. RFC 3261 section 13.2.1: "The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response." RFC 3261 section 13.3.1.4: "If the INVITE did not contain an offer, the 2xx MUST contain an offer if the UAS had not yet sent an offer." RFC 3261 section 14.1: "The same offer-answer model that applies to session descriptions in INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC that wants to add a media stream, for example, will create a new offer that contains this media stream, and send that in an INVITE request to its peer. It is important to note that the full description of the session, not just the change, is sent. This supports stateless session processing in various elements, and supports failover and recovery capabilities. Of course, a UAC MAY send a re-INVITE with no session description, in which case the first reliable non-failure response to the re-INVITE will contain the offer (in this specification, that is a 2xx response)." RFC 3261 section 14.2: "A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP." RFC 6337 section 2.2: "However, when re-INVITEs are sent for non-offer/answer purposes, an offer/answer exchange is required." _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
