[asterisk-bugs] [JIRA] (ASTERISK-22431) Reopened/Cloned - sendrecv in response to recvonly SDP, despite RFC 3264.6 allowed responses (sendonly and inactive only)

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-22431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=209787#comment-209787 ] 

Matt Jordan commented on ASTERISK-22431:
----------------------------------------

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.
                
> Reopened/Cloned - sendrecv in response to recvonly SDP, despite RFC 3264.6 allowed responses (sendonly and inactive only)
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-22431
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22431
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/General
>    Affects Versions: 1.8.10.1
>            Reporter: Jérôme Jolidon
>            Severity: Minor
>         Attachments: asterisk-output.txt
>
>
> The bug I cloned (ASTERISK-15204) is unresolved on 1.8.10.1, 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.
> ****** ADDITIONAL INFORMATION ******
> In 1.6.1.0, 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira