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
