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

Fri Aug 30 07:55:07 CDT 2013

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

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

Hello,
As a matter of fact, I do.
I have the full transaction available if required, but here is the relevant excerpt, acks and trying removed for brevity:

<--- SIP read from UDP:192.168.1.203:5060 --->
INVITE sip:echo at 192.168.1.179:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.203:5060;branch=z9hG4bK-992cdaf966cf4a6cbe20ebd4c5169c53;rport
To: <sip:echo at 192.168.1.179>;tag=as3175074b
From: <sip:alice at asterisk>;tag=214942ec99aa32713dde15a5
Call-ID: 25fb81a7e1044521aecf597b05505bb9
CSeq: 6 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,MESSAGE
Contact: <sip:alice at 192.168.1.203:5060>
Content-Type: application/sdp
Content-Length: 180

v=0
o=- 56602975 2 IN IP4 192.168.1.203
s=SIP Call
t=0 0
m=audio 12000 RTP/AVP 0 8
c=IN IP4 192.168.1.203
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
a=recvonly
<------------->
--- (11 headers 10 lines) ---
Sending to 192.168.1.203:5060 (NAT)
Found RTP audio format 0
Found RTP audio format 8
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0xc (ulaw|alaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x0 (nothing), combined - 0x0 (nothing)
Peer audio RTP is at port 192.168.1.203:12000

Audio is at 17216
Adding codec 0x8 (alaw) to SDP
Adding codec 0x4 (ulaw) to SDP

<--- Reliably Transmitting (NAT) to 192.168.1.203:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.203:5060;branch=z9hG4bK-992cdaf966cf4a6cbe20ebd4c5169c53;received=192.168.1.203;rport=5060
From: <sip:alice at asterisk>;tag=214942ec99aa32713dde15a5
To: <sip:echo at 192.168.1.179>;tag=as3175074b
Call-ID: 25fb81a7e1044521aecf597b05505bb9
CSeq: 6 INVITE
Server: Asterisk PBX 1.8.10.1~dfsg-1ubuntu1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:echo at 192.168.1.179:5060>
Content-Type: application/sdp
Content-Length: 219

v=0
o=root 903423697 903423698 IN IP4 192.168.1.179
s=Asterisk PBX 1.8.10.1~dfsg-1ubuntu1
c=IN IP4 192.168.1.179
t=0 0
m=audio 17216 RTP/AVP 8 0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendrecv

<------------>

<--- SIP read from UDP:192.168.1.203:5060 --->
BYE sip:echo at 192.168.1.179:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.203:5060;branch=z9hG4bK-36360060f5ab452aba49f94830032d47;rport
To: <sip:echo at 192.168.1.179>;tag=as3175074b
From: <sip:alice at asterisk>;tag=214942ec99aa32713dde15a5
Call-ID: 25fb81a7e1044521aecf597b05505bb9
CSeq: 7 BYE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,MESSAGE
Contact: <sip:alice at 192.168.1.203:5060>
Reason: SIP;text="Invalid SDP answer, sdp stream no: 0 stream-mode must be 'recvonly' (RFC 3264 6.)."
Content-Length: 0

> 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
>
> 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