[Home]

Summary:ASTERISK-24146: [patch]No audio on WebRtc caller side when answer waiting time is more than ~7sec
Reporter:Aleksei Kulakov (Each)Labels:
Date Opened:2014-07-31 06:32:37Date Closed:2015-12-10 11:13:46.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/WebSocket Resources/res_rtp_asterisk
Versions:11.11.0 11.20.0 12.4.0 13.6.0 Frequency of
Occurrence
Constant
Related
Issues:
is duplicated byASTERISK-24806 Absent audio between WebRTC clients in local network
Environment:Ubuntu 14.04 Asterisk 12.4.0 compiled from tarball PJProject(https://github.com/asterisk/pjproject 06/JUN/14) --enable-shared --disable-sound --disable-resample --disable-video --disable-opencore-amr --with-external-srtp CFLAGS="-g -DNDEBUG" chromium 35.0.1916.153(rev274914) (launch options: --use-fake-ui-for-media-stream --disable-webrtc-encryption) SIPml-api.js?svn=224Attachments:( 0) badAsterDebug.log
( 1) badCall_filtered.pcapng
( 2) badChromeConsole.log
( 3) badChromeDebug.log
( 4) badChromeWebRtc.log
( 5) chan_sip.patch
( 6) debug.zip
( 7) reproduce-confs.zip
( 8) res_rtp_asterisk.patch
( 9) sip.conf
Description:1. WebRtc caller(354) dials callee(6001) of any type
2. Callee waits 10sec before answering the call.
3. No audio on WebRtc caller(354) side, although RTP is flowing in both directions and callee can hear audio from caller mic.

There is some difference in output of 'rpt set debug on' in *bad* case(+answer wait time > 7sec+):
{quote}
Sent RTP P2P packet to 192.168.0.86:43911 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.139:23506 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.86:43911 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.139:23506 (type 08, len 000160)
{quote}
and *good* case(+answer wait time <7sec+):
{quote}
Sent RTP P2P packet to 192.168.0.86:59092 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.86:59092 (via ICE) (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.86:59092 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.86:59092 (via ICE) (type 08, len 000160)
{quote}

Issue reproducible only with chan_sip. *Chan_pjsip IS NOT affected*
Comments:By: Aleksei Kulakov (Each) 2014-07-31 06:35:07.711-0500

http.conf, extensions.conf - default changes need to make webrtc calls possible
rtp.conf - unchanged

By: Rusty Newton (rnewton) 2014-08-11 16:45:08.352-0500

Probably going to hit unexpected behavior here since encryption is mandated for webrtc. You are running without encryption.

Can you replicate the issue with encryption configured?

I filed ASTERISK-24205 just now as I wasn't able to get DTLS working. If you are able, please comment on that issue.

By: Aleksei Kulakov (Each) 2014-08-12 06:11:25.492-0500

Reproduced even with DTLS enabled on asterisk and chrome side(config attached to ASTERISK-24205)

By: Matt Jordan (mjordan) 2014-08-14 09:55:59.112-0500

This is getting confusing. On ASTERISK-24205 you claimed that it "worked" with your configuration. Here, however, you say that you reproduced the issue with DTLS enabled.

Can you clarify your statements?

By: Aleksei Kulakov (Each) 2014-08-14 12:51:35.700-0500

These are different issues, no?
ASTERISK-24205 is opened by Rusty due to inability to make sucessfull call using DTLS, so i provided  DTLS-enabled config that allows me to make a call.
--------
And there i reported that even with DTLS enabled, there is still the same issue(no audio if callee waits >7 sec before answering call), it is implied that calls with pickup waiting time <7sec is ok.

By: Matt Jordan (mjordan) 2014-08-14 14:33:07.332-0500

Thanks, that clarifies the comment.

By: Dafi Ni (dafi) 2014-08-20 07:51:28.608-0500

I'm also affected. I have configured dtls

pbx - Debian 3.2.60-1+deb7u1 x86_64
asterisk - 11.11.0
chrome -34.0.1847.116 Ubuntu 14.04 aura (260972)

logs in debug.zip

maybe this would be useful or it is related - when attempt calls over wss - outgoing calls works (if answer is less than ~7s) but incoming fails with : [Aug 20 14:37:59] WARNING[30226][C-0000053c]: app_dial.c:2437 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Subscriber absent)


By: Dafi Ni (dafi) 2014-08-20 07:51:57.810-0500

log

By: Dafi Ni (dafi) 2014-08-28 08:00:41.501-0500

versions 12.5.0 , 12-svn, 13.0.0-beta1 are also affected

By: Rusty Newton (rnewton) 2014-09-16 19:25:26.566-0500

I'm going to open this up since multiple people are seeing it. However I'll note that I can't reproduce it yet due to ASTERISK-24205 and ASTERISK-24334.

By: Dafi Ni (dafi) 2014-09-17 02:36:22.820-0500

I'm using different javascript library "JSSIP"

steps for reproduce:
* install one of 11.11 or 12.5.0 , 12-svn, 13.0.0-beta1 asterisk version. (11.11 is first version with "force_avp" config option)
* generate certificates
* use attached configs from file reproduce-confs.zip
* try http://tryit.jssip.net/ with:
** name:153
** SIP uri: 153@ASTERISK_IP_OR_DOMAIN
** SIP password: alamkota
** WS URI: wss://ASTERISK_IP_OR_DOMAIN:8089/ws
** where ASTERISK_IP_OR_DOMAIN could be asterisk ip address, or some domain pointing to this address
** certificate should be for ASTERISK_IP_OR_DOMAIN
* open chrome or chromium browser point to https://ASTERISK_IP_OR_DOMAIN:8089/ws and accept certificate when self-signed or import CA certificate used for sign ASTERISK_IP_OR_DOMAIN certificate
* make call beetween ws->ws  wss->wss  or wss->udp clients with answer time greater than 7second





By: JoshE (n8ideas) 2015-02-18 01:37:06.124-0600

Just a note, I've also run into an identical issue here. The issue will reproduce on fully patched Asterisk 11.15 and 13.2 setups on Chrome Stable and Beta with sipML5 and sipjs.  The telltale sign, as somewhat hinted to above, is that a PCAP will show a second STUN binding request being sent from Chrome to the server.  If the call is answered *after* that second request, there is no audio.  If you catch it before, you will have normal audio.

Haven't dug into a fix for this or looked at the Chrome behavior, but seems to be STUN related.

By: Iulius Ciorica (iulius.ciorica) 2015-03-09 12:19:33.700-0500

Hello all,

For *.pcap files:

https://groups.google.com/group/sip_js/attach/a4832fd73a490d64/no_audio.zip?part=0.1&authuser=0

10.10.14.140 is Asterisk 11.16 (web-rtc over wss)
10.10.10.179 is Google Chrome 40.0.2214.111 (SIP.js / sipML5 over wss)

Call Flow:

Make call from Google Chrome(SIP.js - 1060) to any destination, it can be (SIP Softphone - 1061) or 3G mobile phone via ISDN E1 (TE820 Cards)

So, after some investigations, I found these:


If I answer the call before ~8 seconds from initial invite, my call have audio in both ways:

69 3.633843 10.10.14.140 10.10.10.179 DTLSv1.0 211 Client Hello

 User Datagram Protocol, Src Port: 17642 (17642), Dst Port: 53290 (53290)

70 3.633845 10.10.14.140 10.10.10.179 DTLSv1.0 211 Client Hello

 User Datagram Protocol, Src Port: 17643 (17643), Dst Port: 53290 (53290)

Here you can see, source port are incremented and destination port are not incremented (53290 and 53290).


If I answer the call after ~8 seconds from initial invite, my call do not have audio in any directions

45 9.777806 10.10.14.140 10.10.10.179 DTLSv1.0 211 Client Hello

 User Datagram Protocol, Src Port: 16086 (16086), Dst Port: 55408 (55408)

46 9.778873 10.10.14.140 10.10.10.179 DTLSv1.0 211 Client Hello

 User Datagram Protocol, Src Port: 16087 (16087), Dst Port: 55409 (55409)

Here you can see, source port are incremented and destination port are also incremented (55408 and 55409).

47 9.778930 10.10.10.179 10.10.14.140 ICMP 239 Destination unreachable (Port unreachable)

 Type: 3 (Destination unreachable)
 Code: 3 (Port unreachable)

and so on...

References:

https://groups.google.com/forum/#!topic/sip_js/Gl_kkGUfHCo

Thank you,
Iulius

By: Dade Brandon (dade) 2015-03-29 19:09:09.808-0500

I've confirmed the same persistent problem on 11.16 matching all elements of other contributors to this post.  I was surprised to notice as others do here, that a test extension with a Wait(7) before Answer will never cause this problem (for our testbed, at least),  yet Wait(8) will always cause this error.

- This issue is not present on inbound calls (ie if you wait for 8+ seconds before answering a call inbound to the sip.js phone).
- This issue is present in both firefox and chrome

I'm going to have to put a workaround of answering before initiating any dial command on webrtc users, since our webrtc based release is due on April 1st, however after that I've locked down time to work on this problem.  If anybody else gathers further information that may assist me in developing a patch for this issue, please share it; I am not at all familiar with Stun, Ice or DTLS, so effectively learning the protocols to fix this will take me some time.  If anybody else wants to take this on, then great, but the issue has been stale for too long for me not to stab at it myself.


Is there a workaround anybody is aware of that is not posted here?

Does anybody have a working configuration that does not exhibit this problem?

Does anybody know why this may happen on outbound, but not inbound calls?  ie which settings / code / protocol behaviors are different between the two, that may be at play?

In case there's some common misconfiguration causing this, here is our relevant template for WebRTC/WSS users:

[wss](!)
avpf=yes
transport=wss
icesupport=yes
encryption=yes
dtlsenable=yes
dtlsverify=no
dtlssetup=actpass
dtlscertfile=<valid; self signed.pem>
dtlsprivatekey=<valid; same file as above.pem>
dtlscafile=<valid; self signed ca.crt>
directmedia=no    ; this was added on as a test yesterday, and had no relevant affect;  I was testing to see if reinvites were causing the issue.
rpid_update=no    ; this was added on as a test yesterday, and had no relevant affect

This gets combined with our nat-user template which adds nat=force_rport,comedia, and other implementation specific details that are unlikely to have any relevant affect

Our rtp.conf and http.conf are correct for webrtc/ssl configuration; We don't have any problem other than this.  

By: Dade Brandon (dade) 2015-03-29 21:53:10.011-0500

Retracting my last comment about looking at this bug in a couple weeks;  it's definitely an asterisk bug, however sip.js has an option in their .invite method that allows you to invite without SDP,  which causes ice candidates to generate only after 2xx, right before sending an ack.  The invite without SDP process virtually guarantees that the ice/stun process will take less than eight seconds before the connection is made, thereby avoiding the bug.  

I'll cross post to the sip.js forum referenced a couple comments up

By: Alex Epshteyn (aepshteyn) 2015-06-09 14:52:07.145-0500

We are also experiencing this exact problem in 11.17.0

I notice a link to the SWP 7376 Jira Internal - does this mean that someone is working on the this issue and a resolution can be expected some time soon?

Is there anything we can do to help?

By: Rusty Newton (rnewton) 2015-06-10 07:49:45.186-0500

[~aepshteyn], From: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-FrequentlyAskedQuestions
{quote}
What's the deal with the clone of my issue (SWP-1234)?

You can safely ignore the issues starting with SWP. Digium has a whole group of developers dedicated to working on Asterisk open source issues. They use a separate project for internal time tracking purposes only to avoid cluttering up the main project. The clone being created does not indicate any particular status, and any updates to the issue will be made in the ASTERISK project.
{quote}

Alex, if you can reproduce the issue then you may want to post an archive file containing your debug logs, packet capture and configuration files. That could help whoever looks into the issue.

As was mentioned in the FAQ - any updates or status changes will be indicated on this issue.

By: Alex Epshteyn (aepshteyn) 2015-06-11 02:42:35.611-0500

Here is a description as we understand it:

When outgoing call is initiated by WebRTC extension, if callee picks up the call in 7 seconds everything is fine, if in more than 7 seconds, then the call will have no audio. It appears that in a successful call  Asterisk sends dtls client_hello after 200 OK, and then receives server_hello back from browser. In a bad call (if the the call is not picked up in 7 seconds) Asterisk starts sending client_hello even if there was no 200 OK response. Browser doesn't respond to client_hello, which causes dtls handshake to fail.

Added [bad_call_client_and_server.zip|https://issues.asterisk.org/jira/secure/attachment/52522/bad_call_client_and_server.zip]

By: Eugene Voityuk (sarumjanuch) 2015-06-11 05:27:33.478-0500

Hi, i am working with Alex Epshteyn, an find out additional strange thing. I did trace packets on my machine where client(browser) is running, and i don't see any client_hello packets coming from server to client, but i do see that server is sending them. My suspicions is that  because there is no mapped address yet, because i see that XOR-MAPPED-ADDRESS, is coming only after 200 OK, and as Alex told all client_hello packets are sent before 200 OK if wait more than 7 seconds, so maybe it make some sense. I am attaching tcpdump trace for same call(broken) from server and client.

By: Eugene Voityuk (sarumjanuch) 2015-06-12 07:49:36.234-0500

Good day everyone! Addition, i compiled and installed asterisk 11.18.0, same thing appears to be here. Asterisk is trying to send client_hello packets, i see 8 packets sent away from server, no one reply for them, i don't see them on client machine. if you pick up after those 8 packets, then you will have no audio. I am not an WebRTC expert, and can't find anything regarding sequence of operations here, but i suspect that asterisk stats dtls handshake at a wrong time, i belive that shoud happens when browser will have remoteDescription(SDP from callee), but not on initial SDP from caller, corret me if i am wrong. Also all sip->WebRTC libraries are affected(sipml5,jssip,sip.js), but that even not library level implementation but browser.

By: Eugene Voityuk (sarumjanuch) 2015-06-12 16:05:34.348-0500

Hi Again, new update, now i understand what is going on, maybe it will help you: I added some logic to ast_rtp_on_ice_complete callback, to see the status. Fist of all, calling dtls_perform_handshake() regardless of callback status is not good i think. Second, when you don't pickup in those magic time, the callback is called with next error message: "All ICE checklists failed (PJNATH_EICEFAILED)", and call will have no audio(i believe errors from here should be sent to console). If you picks up before that callback is fired, then you will have call with audio. Additional note, that Browsers set ICE to checking state only after they will have remoteDescription. So ICE checking should start after the ACK from caller to 200 OK, from callee. That will mean, that caller already have remote description, and will be in ICE checking state. Right now ice_start is called for any initial SDP with ICE candidates. Can anyone comment on my thoughts?

By: Eugene Voityuk (sarumjanuch) 2015-06-15 08:12:30.487-0500

Good Day everyone here. I tried to implement what i told in previous comment, in asterisk code, and that made a trick, now ICE checking happens only after answer, and all WebRTC to SIP libraries works fine.. What i tested:
- SIP to SIP not affected
- SIP to WebRTC not affected
- WebRTC to SIP - now works as supposed, can wait until voicemail, forwarded, etc.
- WebRTC to WebRTC - works as supposed.

I am attaching patch files for this issue.
https://issues.asterisk.org/jira/secure/attachment/52531/res_rtp_asterisk.patch
https://issues.asterisk.org/jira/secure/attachment/52530/chan_sip.patch

I am waiting for license agreement sign confirmation. Then i believe we should review this on Gerrit?

By: Iulius Ciorica (iulius.ciorica) 2015-06-16 14:00:25.190-0500

Hi all,

Applying patches attached by Eugene Voityuk over asterisk-11.18.0, solve "7 seconds" issue.

Now, any outbound call from the browser that exceeds ~7 seconds is successful and have sound in both directions.

Before applying this patches any outbound call that exceeds ~7 seconds, stops in ICE state "checking".

ICE connection state changed to "checking"

With the patches applied, outgoing calls get "completed" state.

ICE connection state changed to "completed"

Thank you,
Iulius

By: Eugene Voityuk (sarumjanuch) 2015-06-22 07:41:55.589-0500

Well tried to push to your Gerrit, here what i got: https://gerrit.asterisk.org/#/c/679/

By: Dade Brandon (dade) 2015-06-30 14:36:09.093-0500

This patch didn't work for me, it broke things that were already working.  We have two possible WebRTC settings in production atm that are affectable via a checkbox for our customers, one of the two breaks.


Case 1:    WebRTC has Early Media turned ON, and invites with SDP

              - this case works as intended with and without the patch (this works around the 7 second answer issue regardless of the patch so long as progress is received within 7 seconds)

Case 2:   WebRTC has Early Media turned OFF, and invites WITHOUT SDP

              - this case works as intended without the patch, however with the patch, this case breaks;  Chrome is permanently stuck connecting (I didn't check the state it was stuck in since I had to rush to revert...)


I suspect most people are using a more standard case where early media is off, and invite happens with SDP.   That case is broken without the patch, however since this patch breaks valid use cases, I request that this patch does not get applied to trunk until the cases it breaks are worked out.  I suggest that anybody waiting for the patch instead uses one of the options I've listed above; we developed both specifically out of a need to work around this problem in production, and it works great.   (Note however there's a delay in source updates when using early media in chrome, ie when it switches from generated ringing to an answer, likely a bug in Chrome with authenticating handling source updates (rtp probation in Chrome, not in asterisk,) so I suggest the invite without SDP.


By: Marek Cervenka (cervajs) 2015-08-13 03:47:54.342-0500

this is major showstopper for webrtc with asterisk
is there something what can community do?

By: Vítězslav Ferko (vferko) 2015-08-13 05:34:24.513-0500

This issue persists in versions 13.3.0 and 13.5.0.

By: Eugene Voityuk (sarumjanuch) 2015-08-26 08:07:28.058-0500

For everyone who is using SIP.js. They have own reasons to dont push down remote description from 183 SDP, those reasons are not applied when asterisk is used, so in general they told that they won't fix this, but as workaround you can add such code to outgoing session invite:
{noformat}
           session.on('progress', function (response) {
               var session = this;
               if (response.status_code === 183 && response.body && session.hasOffer && !session.dialog) {
                   if (!response.hasHeader('require') || response.getHeader('require').indexOf('100rel') === -1) {
                       session.mediaHandler.setDescription(response.body).then(function onSuccess () {
                           session.status = SIP.Session.C.STATUS_EARLY_MEDIA;
                           session.mute();
                       }, function onFailure (e) {
                           session.logger.warn(e);
                           session.acceptAndTerminate(response, 488, 'Not Acceptable Here');
                           session.failed(response, SIP.C.causes.BAD_MEDIA_DESCRIPTION);
                       });
                   }
               }
           });
{noformat}
This will pushdown 183 SDP, and Early media is going to work.

By: excendia (excendia) 2015-10-01 16:58:34.866-0500

We are using SIP.js and Asterisk 13.4 for WebRTC.  We did have the same problem with no audio if call is answered after 7 sec.  We applied this patch and it did fix the problem at first when testing with Firefox.  After a few months, we did new tests but now we have a new problem where Asterisk is restarting itself if the call is not answered before 7 sec approx.  One difference from before is we are using a new version of Firefox to do the tests.  We don't know if it is related.  Could anyone help on this issue?  Thanks.

By: Kirill Marchuk (62mkv) 2015-11-13 05:36:13.610-0600

[~sarumjanuch] Eugene, so what about patching Asterisk ? Seems like Joshua comments were not that critical, why the patch was not updated and approved? Do you also believe that there should be a different solution ?

By: Eugene Voityuk (sarumjanuch) 2015-11-15 11:27:39.454-0600

Well, i just didn't have enough time to fix that... Will try to send clean patch this week. No, there is no other clean way to fix that. Old chan_sip is trying to start ICE negotiation just as it receives an SDP from originator, but browsers will not be ready to do ICE negotiations until they have remote description (SDP from remote). And timeout for ICE negotiation is ~6-7 secs in asterisk. This is that magic time in this issue. After timeout asterisk will never try to start negotiation again, and don't drop the call. So you end up with asterisk already stoped trying to negotiate ICE, and browser which hangs forever in checking state. You might hack this by sending the early media to WebRTC endpoint, just as asterisk receive incoming invite from it (this will force asterisk to send it SDP to WebRTC endpoint and they will be able to negotiate ICE). But i don't believe this is good solution. Other thing is to do invite without SDP, which even worse then previous in my opinion as you will end up with having huge (in my opinion this is huge, sometimes you will need 4-5 secs to gather all needed candidates) delay with no sound after call pickup.

By: Eugene Voityuk (sarumjanuch) 2015-11-15 11:31:19.222-0600

As for asterisk 13 i don't know nothing, as i never installed it yet, but for WebRTC and incoming calls to Firefox there is an issue ASTERISK-25265, which i also created my own patch for asterisk 11. In patch for asterisk 13(not mine) i have seen that they require asterisk to be compiled with the latest version of OpenSSL, i don't know was this patch committed to 13, but you can check.

By: Kirill Marchuk (62mkv) 2015-11-15 22:46:40.113-0600

Thanks [~sarumjanuch], I for one will be happy to see the patch from you. As of ASTERISK-25265, it has already been fixed in Asterisk 13.6.0, thanks to the guys too!

By: Kirill Marchuk (62mkv) 2015-11-23 05:14:48.267-0600

Hi [~sarumjanuch], any updates on the patch ?

I also wonder if anybody has done any research in regards with the following statement:
" browsers will not be ready to do ICE negotiations until they have remote description (SDP from remote)."

Is this behaviour compliant with WebRTC specs ?

By: Eugene Voityuk (sarumjanuch) 2015-11-23 06:13:16.610-0600

Hi Kirill, this behavior is ICE specific. When media is started and each party has got the SDP of the remote party, they will start procedures called ICE connectivity checks, or ICE negotiation. The ICE connectivity check is done by pairing each candidate in local SDP with the candidates found in remote SDP, and perform connectivity check for each pair by sending STUN Binding request to the remote address in the pair. When this STUN Binding Request yields a successful response, then the party knows that this pair of local and remote candidates may be used for the media transmission. The remote party will do the same pairing and connectivity checks process too. When asterisk receives remote SDP with candidates it creates own response with own candidates in SDP and based on that it can already create pairs of local and remote candidates to check, and that what it is doing right now, stating ICE checks as soon as asterisk have  pairs. But browser is not yet received response from asterisk with asterisks candidates, and just can't create pairs to start negotiation. My patch is fixing that by starting ICE checking only after sending response to remote WebRTC endpoint (browser).

https://tools.ietf.org/html/rfc5245

By: Kirill Marchuk (62mkv) 2015-11-29 21:22:41.899-0600

Hi [~sarumjanuch]!

> My patch is fixing that by starting ICE checking only after sending response to remote WebRTC endpoint (browser).

So is the patch already sent to Gerrit, or what is the progress on this ?

By: Matt Jordan (mjordan) 2015-11-30 08:26:05.987-0600

[~62mkv]: If you click on the *Gerrit Reviews* tab, you can see the reviews that were created for this issue and their current status.

Both are Abandoned, as [~eugene.voityuk] didn't respond to peer review findings.

By: Kirill Marchuk (62mkv) 2015-11-30 23:23:23.981-0600

The "Affects Version" for this bug does not mention 13 branch; does it mean Asterisk 13 (with chan_sip) is not affected ?

By: Richard Mudgett (rmudgett) 2015-12-01 11:19:20.642-0600

No.  It just means that the issue was reported against those specific versions.  Generally, if an issue is reported against a version it also affects newer versions until the issue is fixed.

By: Eugene Voityuk (sarumjanuch) 2015-12-02 16:13:32.388-0600

https://gerrit.asterisk.org/#/c/1751/ New review created.

By: Kirill Marchuk (62mkv) 2015-12-03 06:12:36.598-0600

I can confirm this patch solves the described pronlem with Asterisk 13.6.0

I would ask responsible persons to please approve it and include in the next release

UPD: it does not apply cleanly on Asterisk 13, because it's based on Asterisk 11 source, but with some effort it works, and that's the most important!

By: Kirill Marchuk (62mkv) 2015-12-10 02:24:49.055-0600

Now, that it's merged into "13" branch, what is the expected release timeline ?

By: Joshua C. Colp (jcolp) 2015-12-10 05:58:42.990-0600

Within the next few weeks.

By: Eugene Voityuk (sarumjanuch) 2015-12-10 12:02:32.259-0600

Victory! GG :)

By: Iulius Ciorica (iulius.ciorica) 2015-12-10 13:01:31.908-0600

Thank you all for your efforts! :)

By: viniciusfontes (viniciusfontes) 2015-12-16 12:07:08.672-0600

On Asterisk 13.7.0-rc1 WSS connections won't work anymore.

Here's the WS request and headers on 13.6.0: http://i.imgur.com/3PvPiwO.png
And here's the WS request and headers on 13.7.0-rc1: http://i.imgur.com/6eptuyX.png

There were no changes in config files. If I go back to 13.6.0 it works fine.

On Asterisk CLI, this message shows up on 13.7.0-rc1:

[Dec 16 15:53:37] WARNING[10534]: res_http_websocket.c:791 __ast_websocket_uri_cb: WebSocket connection from 'REDACTED:60976' could not be accepted - no protocols out of 'sip' supported

By: viniciusfontes (viniciusfontes) 2015-12-16 12:42:28.421-0600

Just found out that the issue happens both with WS and WSS.

By: Kevin Harwell (kharwell) 2015-12-16 13:05:11.168-0600

[~viniciusfontes]

A new option was added to chan_sip that enables/disables the websocket. If you don't have it specified yet then try setting the following to true in your sip.conf under the [general] section in order to enable it:

websocket_enabled = true


By: viniciusfontes (viniciusfontes) 2015-12-16 13:47:31.355-0600

[~Kevin Harwell]
That solved the issue, thanks!

By the way, I can also confirm the patch solves the early media bug.

By: Joshua C. Colp (jcolp) 2015-12-17 09:11:37.186-0600

The requirement of "websocket_enabled = true" is a regression in the release candidate and will be fixed in the next one.