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

[Russ Penar <[e-mail]>]

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.


Best regards,

Russ Penar


For existing dialog reInvite (session modification), are you aware of a use case where SIP endpoint would signal a=sendonly with intention other than call hold?
(extracts in scope for easy reference below)

  *   "[RFC3264] specifies [...] that "hold" should

   be indicated in an established session by sending a new offer
   containing "a=sendonly" attribute for each media stream to be held.
   An answerer is then to respond with "a=recvonly" attribute to
   acknowledge that the hold request has been understood."



  *   "Note that the use of sendonly/recvonly is not limited to hold.  These

   may be used for other reasons, such as devices that are only capable
   of sending or receiving.  So receiving an offer with "a=sendonly"
   attribute must not be treated as a certain indication that the
   offerer has placed the media stream on hold."


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