Summary:ASTERISK-22431: Reopened/Cloned - sendrecv in response to recvonly SDP, despite RFC 3264.6 allowed responses (sendonly and inactive only)
Reporter:Jérôme Jolidon (jjolidon)Labels:
Date Opened:2013-08-30 08:05:06Date Closed:2013-08-30 11:51:24
Versions: Frequency of
is the original version of this clone:ASTERISK-15204 Responds sendrecv to recvonly SDP, but RFC 3264 says sendonly and inactive are only possible replies
Environment:Attachments:( 0) asterisk-output.txt
Description:The bug I cloned (ASTERISK-15204) is unresolved on, I reopened because:
a) I have a logged sip sequence, and
b) I have a use case for the resolution (voluntarily mute microphone in conference but keep listening)

Below is the original description.
Jérôme Jolidon


Whilst looking at possible solutions to ASTERISK-15145, I noticed that Asterisk can never send a sendonly SDP response.  Moreover it treats an inbound recvonly as an unrecognized case.  The result is that it sends the default sendrecv response.

RFC 3624 says that the only acceptable responses to recvonly are sendonly and inactive.  I.E., reading between the lines, the response cannot offer more capabilities than the request would allow.


In, where I first noticed this, the recognition is performed inline, but a subroutine is used in trunk.  However, in both cases, the variable sendonly is left to default to -1.

In both, the page 2 hold flags are set to SIP_PAGE2_CALL_ONHOLD_ACTIVE if sendonly isn't 1 or 2 (found sendonly or found inactive), and in both cases, sendrecv is set in the response as a result of defaulting after not explicitly testing for SIP_PAGE2_CALL_ONHOLD_ACTIVE.

At this stage, this report is based on code reading.  I'm not yet aware of something that might offer recvonly to Asterisk.  (I do have a case where I might want to offer/respond sendonly.)

RFC 3264, section 6.1, paragraph 2:

If a media stream is
  listed as recvonly in the offer, the answer MUST be marked as
  sendonly or inactive in the answer.
Comments:By: Matt Jordan (mjordan) 2013-08-30 11:51:18.569-0500

There's no need to clone an issue.

Next time, please contact a bug marshal in #asterisk-bugs, or just comment on the issue that it needs to be re-opened. A bug marshal will be along to reopen the particular issue.

I'm closing this out as a duplicate of ASTERISK-15204 and re-opening the original issue.