Re: [sipcore] [EXTERNAL] Re: 3264 offer a=sendonly in context of session modification

Hi all,

In Linphone application, we use a=sendonly for video streams within a
conference. Each client sends a miniature (very low resolution) video
stream to the conference server, and each participant can claim receiving
such miniature video streams of other participants with a=recvonly and
a=label attributes. This a way to achieve advanced video conference
presentation without requiring a codec with spatial scalability.

In any case, we can hardly assume that sendonly means "put on hold". That
may be a problem indeed that the signaling does not explicitely indicates
it.
"On hold" is a notion that only exists for the participant that presses the
"pause" button actually.

Best regards.

Simon

Le sam. 18 nov. 2023, 09:57, Mojtaba Esfandiari.S <esfandiari.m84@gmail.com>
a écrit :

> Hello all,
> As my experiences when I had been developing the RTSP module for kamailio,
> I used this option, because I just needed to get a one-way real stream from
> Camera. In that situation, I have to change the SDP parameter to a=recvonly
> or a=sendonly.
> WIth Best Regards
> Mojtaba Esfandiari.S
>
> On Sat, Nov 18, 2023 at 12:25 AM Paul Kyzivat <pkyzivat@alum.mit.edu>
> wrote:
>
>> On 11/17/23 11:55 AM, Russ Penar wrote:
>> > Paul,
>> >
>> > Thank you for the reply and follow up.
>> >
>> > Paul Kyzivat wrote:
>> >>   Are you asking as a recipient of such an offer? If so, why does it
>> > matter?
>> >
>> > Yes, as an offer recipient a client's UI indicates remote party call
>> hold.
>> > Client logic triggers UI update today based on a=inactive update for
>> > established session.
>>
>> Just to be clear, you are saying that "other party" sends an in-dialog
>> offer (via either reINVITE or UPDATE) with a=sendonly, and the client
>> you are concerned about sends a corresponding answer with a=inactive?
>>
>> That is a valid response, as would be a=recvonly.
>>
>> > To progress the client's 3264 interworking support discussion, I must
>> > determine the risk of introducing my interpretation of 3264 8.4, " With
>> > conditions met, new offer for established session, supporting
>> a=sendonly
>> > modification (in addition to inactive) does not break the existing UI
>> > experience of remote party call hold indication."
>>
>> Do you have reason for concern that the a=inactive is wrong in this
>> circumstance? IIUC your implementation is *presuming* that the other
>> party is requesting to put the call on hold, and deciding that it
>> doesn't want to received the media. (Presumed to be music on hold.)
>>
>> On what basis would you make any determination? Did the media exchanged
>> prior to the "hold" cause your user to be surprised to no longer get
>> media?
>>
>> > *8.4 <https://www.rfc-editor.org/rfc/rfc3264#section-8.4>** Putting a
>> > Unicast Media Stream on Hold*   If a party in a call wants to put the
>> > other party "on hold", i.e.,    request that it temporarily stops
>> > sending one or more unicast media    streams, a party offers the other
>> > an updated SDP.    If the stream to be placed on hold was previously a
>> > sendrecv media    stream, it is placed on hold by marking it as
>> > sendonly.  If the    stream to be placed on hold was previously a
>> > recvonly media stream,    it is placed on hold by marking it inactive.
>>
>> I suggest you read RFC 6337, especially section 5, for an in-depth
>> discussion of this topic.
>>
>>         Happy Reading,
>>         Paul
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>