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

[Richard Mudgett (JIRA)]

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

Richard Mudgett updated ASTERISK-22431:
---------------------------------------

    Description: 
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.

  was:
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.

    
> 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