Hi, Based upon the shown message flow, the behavior appears to be incorrect. More specifically, it looks like UAC1 desired sendrecv within step 1. If UAC1 still prefers sendrecv, it should have offered sendrecv within step 5.
The following are a few RFC snippets. 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 5.1: "A UA should send an offer that indicates what it, and its user, are interested in using/doing at that time, without regard for what the other party in the call may have indicated previously. This is the case even when the offer is sent in response to an INVITE or re- INVITE that contains no offer. (However, in the case of re-INVITE, the constraints of [RFC3261] and [RFC3264] must be observed.)" RFC 6337 section 5.3: "If a UA has occasion to send another offer in the session, without any desire to change the hold status (e.g., in response to a re- INVITE without an offer, or when sending a re-INVITE to refresh the session timer), it should follow the "General Principle for Constructing Offers and Answers" (Section 5.1). If it previously initiated a "hold" by sending "a=sendonly" attribute or "a=inactive" attribute, then it should offer that again. If it had not previously initiated "hold", then it should offer "a=sendrecv" attribute, even if it had previously been forced to answer something else. Without this behavior it is possible to get "stuck on hold" in some cases, especially when a 3pcc is involved." > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of isshed > Sent: Wednesday, June 03, 2015 3:14 AM > To: sip-implementors > Subject: [Sip-implementors] SDP attribute for hold and rersume > > Hi All, > > Below is the scenario.. > > UAC1--------------------------------------------------------------------UA C2 > > 1)---------------------INVITE (a=sendrecv)-------------------------> > 2)<---------------------200-OK(a=recvpnly)------------------------- > 3)-------------------------------ACK-------------------------------------- > > > 4)<---------------------INVITE (withoutsdp)------------------------- > 5)---------------------200-OK(a=sendonly)-------------------------> > 6)<---------------------------ACK (a=inactive)----------------------- > > in step 4 UAC2 send INVITE without SDP and in 200-OK UAC1 is responding with > a=sendonly attribute. Question is if UAC1 is behavior is correct is not? > > if not, please suggest correct bahaviour. > > Thanks _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
