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

[Russ Penar <[e-mail]>]

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.

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."


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.




Best regards.

Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: sipcore <[e-mail]> on behalf of Paul Kyzivat <[e-mail]>
Sent: Friday, November 17, 2023 7:45 AM
To: [e-mail] <[e-mail]>
Subject: [EXTERNAL] Re: [sipcore] 3264 offer a=sendonly in context of session modification

Russ,

On 11/17/23 9:09 AM, Russ Penar wrote:
> Greetings and salutations,
>
> In your work (especially in the wild) have you come across offers with
> a=sendonly (in context of existing dialog session update) outside of
> hold scenarios?
> If yes, please share the scenario and related trivia.
>
> I understand /new /dialog offer with a=sendonly likely (always?) signals
> a scenario other than hold.
>
> For /existing /dialog session update offer with a=sendonly, I have not
> been successful in identifying an applicable scenario (beyond hold) and
> request your expert perspective(s) please.

I don't know of such an example. But I wonder why you ask. Are you
asking as a recipient of such an offer? If so, why does it matter? The
behavior you produce in response is governed by what is in the offer,
the internal state of your endpoint, and the desires of the user of your
endpoint (to the extent that you know them.) It should not depend on
your inference of the desires of the other device or its users.

        Thanks,
        Paul

_______________________________________________
sipcore mailing list
[e-mail]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=05%7C01%7Crussp%40microsoft.com%7C50b87b3a60fa411f84fc08dbe7844a7d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638358327637954589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zIVlZtTEbKWEIFj45XaeyzGyE9Hx7RxEM%2Fm9Fp5c2Ks%3D&reserved=0<https://www.ietf.org/mailman/listinfo/sipcore>