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

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
>