| Summary: | ASTERISK-15204: Responds sendrecv to recvonly SDP, but RFC 3264 says sendonly and inactive are only possible replies | ||||
| Reporter: | David Woolley (davidw) | Labels: | |||
| Date Opened: | 2009-11-23 11:26:24.000-0600 | Date Closed: | |||
| Priority: | Minor | Regression? | No | ||
| Status: | Open/New | Components: | Channels/chan_sip/General | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) asterisk-output.txt | |||
| Description: | 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. | ||||
| Comments: | By: Leif Madsen (lmadsen) 2009-12-04 09:30:24.000-0600 Is this related (or a duplicate) of issue ASTERISK-15258 ? By: David Woolley (davidw) 2009-12-04 09:42:51.000-0600 Related but not duplicate. See my comment on ASTERISK-13496 which goes into more detail and lists a total of four where this RFC keeps cropping up as a factor, even if it isn't the primary issue. It's not duplicate, because the current one is about receiving recvonly, whereas the other one is about receiving sendonly. By: warlock52 (warlock52) 2010-06-22 21:19:23 Hi, we have run into an issue today after having upgraded from 1.4 to 1.6.2.9 last week. We are using a SIP SDK that has been without an issue with Asterisk 1.4 for over 8 months now but when upgrading to 1.6.2.9 certain funtions do not work any longer. One of them is according to the SDK provider (www.pcbest.net) the incorrect response to a HOLD feature from the SDK-Softphone where Asterisk should respond with return a=recvonly but the Asterisk server returns a=sendrecv. How can we get arround this because with this a the hold function for the SIP clients using the SDK no longer works. The Audio is never suspended and the customer still hears us talking. By: warlock52 (warlock52) 2010-06-22 21:40:57 According to www.pcbest.net the following is happening with the re-invite that is sent when sending the hold request: Hold message is an re-INVITE message with audio attribute set to readonly, and Asterisk server should return a=recvonly. But Asterisk server still return sendrecv. By: David Woolley (davidw) 2010-06-28 06:19:16 I'm afraid your report is confused. There is no "readonly" attribute, only recvonly. The correct responses to recvonly are sendonly or inactive. In practice, the only way of putting on hold which will work with most PABXes is to send sendonly. I suspect your real problem here may be that Asterisk doesn't track media direction information for individual streams, which is a different issue, and should be raised as such (if not already in the system). You definitely need to either follow the SIP problem reporting rules and provide a sip set debug trace at appropriate verbosity, or to identify exactly what is wrong in the code. By: warlock52 (warlock52) 2010-08-14 21:39:27 we have a workarround that has currently helped us to stay out of trouble...setting "ignoresdpversion=yes" in sip.conf has suppressed the issue...this just as a tip for others that have run into the same problem. By: Leif Madsen (lmadsen) 2010-08-31 12:00:02 Suspending this issue. No SIP debug information supplied as requested. Please reopen if you are able to supply said information. Thanks! By: Jérôme Jolidon (jjolidon) 2013-08-30 07:54:17.074-0500 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: [Please see attached file] By: Jérôme Jolidon (jjolidon) 2013-08-30 07:56:10.329-0500 Full transaction, including call setup and ending, of Asterisk infringing RFC 3264.6 By: David Woolley (davidw) 2013-09-02 05:20:21.528-0500 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. In particular, from my original comment, this would have be discovered by reading the code, and we were commited to changing that part of the code, anyway, so setting up a test case to prove an obvious fault would have been wasted effort, for us. 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. (I think it was done as part of a much larger change.) 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. By: Matt Jordan (mjordan) 2015-02-25 20:35:40.773-0600 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@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@127.0.0.3:5060>;tag=1 To: phone_A <sip:phone_B@127.0.0.1> CSeq: 103 INVITE Call-ID: 23ac0f0b271a59814219023c06a3df56@127.0.0.1:5060 Contact: <sip:phone_B@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@127.0.0.3:5060>;tag=1 To: phone_A <sip:phone_B@127.0.0.1> Call-ID: 23ac0f0b271a59814219023c06a3df56@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@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@127.0.0.3:5060>;tag=1 To: phone_A <sip:phone_B@127.0.0.1>;tag=as463cda74 Call-ID: 23ac0f0b271a59814219023c06a3df56@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@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} By: Jérôme Jolidon (jjolidon) 2015-10-05 08:11:10.700-0500 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). | ||||