Howdy, RFC 6337 and 3GPP TS 24.610 (http://www.3gpp.org/ftp/Specs/html-info/24610.htm) appear to be in conflict concerning resuming from hold. However, it may just be a poor interpretation of 3GPP TS 24.610 when a sendonly offer (from X) is answered with inactive (by Y).
3GPP TS 24.610 section 4.5.2.1 appears to indicate that X should offer recvonly instead of sendrecv when resuming. RFC 6337 section 5.3 explicitly indicates that X would offer sendrecv. Anyone know if discrepancy is intentional? Thanks, Brett ----- RFC 6337: "Once in this state, to resume a two-way exchange of media, each side must reset its local hold status. If UA1 is first to go off hold, it will then send an offer with "a=sendrecv" attribute. The UA2 will respond with its desired state of "a=sendonly" attribute because that is a permitted response. When UA2 desires to also resume, it will send an offer with "a=sendrecv" attribute. In this case, because UA1 has the same desire it will respond with "a=sendrecv" attribute. In the same case, when UA2 receives the offer with "a=sendrecv" attribute, if it has decided it wants to reset its local hold but has not yet signaled the intent, it may send "a=sendrecv" attribute in the answer." ------ 3GPP TS 24.610: "If all the media streams that shall be resumed, the invoking UE shall generate a session level direction attribute, or separate media level direction attributes, in the SDP that is set to: - "recvonly" if the streams were previously inactive media streams; or - "sendrecv" if the streams were previously sendonly media streams, or the attribute may be omitted, since sendrecv is the default." _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
