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

Wed Feb 25 20:37:34 CST 2015

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

Matt Jordan commented on ASTERISK-15204:
----------------------------------------

Confirmed that this is still an issue in the latest 11 branch:

{noformat}
[Feb 25 20:33:44] VERBOSE[25453] chan_sip.c: --- (12 headers 0 lines) ---
[Feb 25 20:33:47] VERBOSE[25453] chan_sip.c: 
<--- SIP read from UDP:127.0.0.3:5060 --->
INVITE sip:phone_A at 127.0.0.1:5060 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.3:5060;branch=z9hG4bK-25462-1-7
From: phone_B <sip:phone_B at 127.0.0.3:5060>;tag=1
To: phone_A <sip:phone_B at 127.0.0.1>
CSeq: 103 INVITE
Call-ID: 23ac0f0b271a59814219023c06a3df56 at 127.0.0.1:5060
Contact: <sip:phone_B at 127.0.0.3:5060>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
User-Agent: PolycomSoundPointIP-SPIP_430-UA/3.2.3.1734
Accept-Language: en
Supported: 100rel,replaces
Allow-Events: talk,hold,conference
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 193

v=0
o=- 1325003603 1325003604 IN IP4 127.0.0.3
s=Polycom IP Phone
c=IN IP4 127.0.0.3
t=0 0
m=audio 2226 RTP/AVP 0 101
a=recvonly
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
<------------->
[Feb 25 20:33:47] VERBOSE[25453] chan_sip.c: --- (15 headers 9 lines) ---
[Feb 25 20:33:47] VERBOSE[25453][C-00000000] chan_sip.c: Sending to 127.0.0.3:5060 (no NAT)
[Feb 25 20:33:47] VERBOSE[25453][C-00000000] chan_sip.c: 
<--- Transmitting (no NAT) to 127.0.0.3:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 127.0.0.3:5060;branch=z9hG4bK-25462-1-7;received=127.0.0.3
From: phone_B <sip:phone_B at 127.0.0.3:5060>;tag=1
To: phone_A <sip:phone_B at 127.0.0.1>
Call-ID: 23ac0f0b271a59814219023c06a3df56 at 127.0.0.1:5060
CSeq: 103 INVITE
Server: Asterisk PBX SVN-branch-11-r432280
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:phone_A at 127.0.0.1:5060>
Content-Length: 0

<------------>
[Feb 25 20:33:47] VERBOSE[25453][C-00000000] chan_sip.c: Audio is at 9074
[Feb 25 20:33:47] VERBOSE[25453][C-00000000] chan_sip.c: Adding codec 100003 (ulaw) to SDP
[Feb 25 20:33:47] VERBOSE[25453][C-00000000] chan_sip.c: Adding non-codec 0x1 (telephone-event) to SDP
[Feb 25 20:33:47] VERBOSE[25453][C-00000000] chan_sip.c: 
<--- Reliably Transmitting (no NAT) to 127.0.0.3:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.3:5060;branch=z9hG4bK-25462-1-7;received=127.0.0.3
From: phone_B <sip:phone_B at 127.0.0.3:5060>;tag=1
To: phone_A <sip:phone_B at 127.0.0.1>;tag=as463cda74
Call-ID: 23ac0f0b271a59814219023c06a3df56 at 127.0.0.1:5060
CSeq: 103 INVITE
Server: Asterisk PBX SVN-branch-11-r432280
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:phone_A at 127.0.0.1:5060>
Content-Type: application/sdp
Content-Length: 243

v=0
o=root 1675464711 1675464711 IN IP4 127.0.0.1
s=Asterisk PBX SVN-branch-11-r432280
c=IN IP4 127.0.0.1
t=0 0
m=audio 9074 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<------------>
{noformat}

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