[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] changing the Direction Attributes.
From:       ankur bansal <abh.ankur () gmail ! com>
Date:       2013-11-27 5:50:28
Message-ID: CA+22TkDVeU2sQ820BGwF4k9yLR9Fe7vEpdvHA40QfeHypwfu8Q () mail ! gmail ! com
[Download RAW message or body]

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 <pkyzivat@alum.mit.edu> 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 <pkyzivat@alum.mit.edu
>> <mailto:pkyzivat@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
[prev in list] [next in list] [prev in thread] [next in thread]