What even is this and why am I here? 😔👌 On Wed, 9 Sep 2020 at 14:14, Dale R. Worley <wor...@ariadne.com> wrote:
> Shaun Stokes <shaun@sysconfig.cloud> writes: > > The problem occurs when the 3rd party sends an SDP with the media > > attribute 'a=sendonly' on an existing session then follow with a > > RE-INVITE with-out an SDP, they claim that our 2xx offer in response > > should contain an SDP with-out 'a=sendonly' (or replace with > > 'a=sendrecv') based on the interpretation of a "brand new call" used > > below. Anthony Minessale II (FreeSWITCH lead) claims that "brand new > > call" is only intended to refer to codecs (not all media attributes) > > and that the 3rd party (Broadsoft) invented this concept on their own. > > You aren't providing a very clear description of the specific sequence > of events. But I don't think that matters. There are general > principles which clarify many situations. > > The first principle is that the standards allow devices a wide range of > behaviors, and many allowed behaviors are not very useful in practical > systems. In the case of providing SDP within an existing dialog, there > are specific rules that a particular media stream (a sequential m-line > in the SDP) may not change its media type, and codec numbers should not > be assigned to different codecs. But there is no MUST about e.g. what > directional attributes must be supplied. > > The second general principle is that when a UA provides an offer, it > should (but not must) offer all the communication possbilities it is > willing to support (at that moment). Adhering to this maximizes the > chance that the two UAs will agree on SDP that allows useful > communication. > > A third general principle is that when a UA receives an answer, it must > be prepared to receive any subset of what it offered, and make the best > of it. > > A fourth general principle is that when a UA receives an offer, it must > be prepared to receive pretty much anything (within the few rules that > apply to offer/answer generally), and provide an answer which is some > subset of the offer. > > If you want a more detailed analysis, you'll have to provide a skeleton > of an actual message exchange. And for that matter, a clear statement > of what you don't like about the situation. > > One item I notice in your text, and I cannot tell whether it is simply a > typo, is that you speak of the far endpoint sending SDP with a=sendonly, > that is, media coming to you but not from you. Then you speak of the > near endpoint sending SDP with a=sendonly, which means, media coming > from you but not to you. If the near endpoint was attempting to repeat > the current status of the media session, it would send a=recvonly. > > As stated, the offer by the near endpoint is a=sendonly, and if the far > endpoint is in a state where it is only willing to send media, the > answer must contain a=inactive. That leaves a state that is > standards-compliant, but probably not useful. > > Dale > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
