Thanks!!
On Wed, Jun 3, 2015 at 5:39 PM, Brett Tate <br...@broadsoft.com> wrote: > 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