Hi Sip-implementors,
Thank you for contacting us！ May I have your order number please? And
please offer the email address and full name that you filled in when you made
this order on our website.
So I can check it for you. Serene Chen
On
Thu, 10 Sep at 12:00 AM
, Sip-implementors
<[email protected]> wrote:
Send Sip-implementors mailing list submissions to
[email protected] To subscribe or unsubscribe via the
World Wide Web, visit
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors or, via email,
send a message with subject or body 'help' to
[email protected] You can reach the person
managing the list at [email protected] When
replying, please edit your Subject line so it is more specific than "Re:
Contents of Sip-implementors digest..." Today's Topics: 1. Re: RFC 3261
section 14.2 - "brand new call" does not specify whether the SDP should
modify media attributes of an existing session containing a=sendonly or
a=recvonly (Dale R. Worley)
----------------------------------------------------------------------
Message: 1 Date: Tue, 08 Sep 2020 22:13:49 -0400 From: [email protected] (Dale
R. Worley) To: Shaun Stokes <[email protected]> Cc:
[email protected] Subject: Re: [Sip-implementors] RFC 3261
section 14.2 - "brand new call" does not specify whether the SDP should
modify media attributes of an existing session containing a=sendonly or
a=recvonly Message-ID: <[email protected]> Content-Type:
text/plain Shaun Stokes <[email protected]> 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
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors End of
Sip-implementors Digest, Vol 77, Issue 2
***********************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
