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 <pkyzi...@alum.mit.edu
> <mailto:pkyzi...@alum.mit.edu>> 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
> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
