[asterisk-bugs] [JIRA] (ASTERISK-15204) Responds sendrecv to recvonly SDP, but RFC 3264 says sendonly and inactive are only possible replies

[Jérôme Jolidon (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-15204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jérôme Jolidon updated ASTERISK-15204:
--------------------------------------

    Attachment: asterisk-output.txt

Full transaction, including call setup and ending, of Asterisk infringing RFC 3264.6
                
> Responds sendrecv to recvonly SDP, but RFC 3264 says sendonly and inactive are only possible replies
> ----------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-15204
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-15204
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/General
>            Reporter: David Woolley
>            Severity: Minor
>         Attachments: asterisk-output.txt
>
>
> 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