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

[David Woolley (JIRA)]

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

David Woolley commented on ASTERISK-15204:
------------------------------------------

Incidentally, I wasn't asked for a SIP trace and I felt that the detailed analysis should have been enough.  Somehow I missed the closing of the issue - I think there might have been a problem with notification emails at the time.

We worked round this by major surgery of the code, but that is on the 1.6.1.0 code base, and I don't think I'll be able to get time to move the patch forward.

Basically we added a parameter to, I think it was, send SDP, to indicate whether or not it was the offer or response, and we tracked flags for send and receive allowed, as seen by the two different sides.  I can probably have a look at what I did and give a slightly better description.
                
> 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