Hi Paul , Yes this seems more logical from general implementation .thanks
Regards Ankur Bansal On Tue, Nov 26, 2013 at 9:37 PM, Paul Kyzivat <[email protected]> wrote: > On 11/26/13 9:06 PM, ankur bansal wrote: > >> Hi Aditya >> >> I think this is valid from protocol and offer answer model .But its >> actually driven by use-case. >> >> *Usecase 1* :Normally during call(sendrecv :media flowing both ways) if >> >> we put call on hold (no music on hold) with inactive >> then *while resuming ,we put sendrecv*. >> >> *Usecase 2* :But for the scenario where media flowing one way(sendonly) >> >> like Video Share or Image Share from User A to User B >> And call is put on hold using inactive then*while >> resuming will put sendonly* again . >> >> *Usecase 3 *: *With MOH * >> >> >> User A(sendrecv) <--------------------In call------------------ > User >> B(sendrecv) >> >> A holds(sendonly)------------------one way hold(MOH)--------- - > User >> B(recvonly) listening to music >> >> A(inactive) <--------------------------2 way hold--------------- >> User B holds(inactive) >> > > So far so good. But I have issues below. > Again, please read RFC 6337, especially sections 5.3 and 5.1. > > *Now 2 cases possible depending who resumes firs*t >> >> *When A resume first:* >> > > A had initiated hold, and now wants to resume. A's desired state is > sendrecv. > > > A resumes(recvonly)------------------still call held from B--------- - >> > User B(sendonly) >> > > So A above should offer sendrecv, since that is his desired state, > regardless of what B wanted. > > Assuming B still wants to be on hold, it should then probably respond with > sendonly, doing MOH. The end state is same as yours, but the means are > different. > > > A(sendrecv) <--------------------------Both way active-------------- >> User B resumes(sendrecv) >> > > Yes. > > *When B resume first:* >> > > In this case B presumably wants sendrecv. > > > A (sendonly) <------------------still call held from A--------- - --- >> User B resumes (recvonly) >> > > So B should offer what it wants (sendrecv). Assuming A still wants to be > on hold, then A will answer sendonly for MOH. > > A resumes(sendrecv) -------------------------Both way >> active--------------> User B (sendrecv) >> >> >> *So while resuming call , both users putting recvonly.* >> > > As I showed above, it works as well in these cases to resume using > sendrecv, and it is safer. You really never know what is going on at the > other end, so you should make no assumptions about the other end when you > generate your offer. The other end can deal with what it wants in the > answer. > > Thanks, > Paul > > Hope this helps >> >> Regards >> Ankur Bansal >> >> >> On Mon, Nov 25, 2013 at 6:30 AM, Paul Kyzivat <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 11/24/13 10:21 PM, Aditya Kumar wrote: >> > Hi, >> > Is the following valid. >> > A keeps B on Hold with SDP -inactive. state on both sides >> offer-answer is inactive. >> > Can A send again offer with SDP as (sendonly)--?. is this valid? >> > if so can you plesae point me the reference/ >> >> See RFC 6337, especially sections 5.3 and 5.1. >> >> Best wishes, >> Paul >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> >> > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
