[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:comment-tabpanel&focusedCommentId=227776#comment-227776 ] 

Jérôme Jolidon commented on ASTERISK-15204:
-------------------------------------------

Also, I have a possible use case in mind: mute the microphone when connected to a conference in order to limit the bandwidh use (and possibly the workload of the server).

> 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 was sent by Atlassian JIRA
(v6.2#6252)