So in the last week I have gotten Sipml5 finally working properly with the newest asterisk release (11.5) And now I seem to have run into an issue with hold/resume. I havent exactly pinned down the issue with the hold/resume.
its either that Asterisk is generating a new encryption key when it comes off of hold (why would this be happening). Or because the Canidates in the Console are turning to the server and 127.0.0.1 instead of my local IP and the server or my local IP and my public IP.
Does/did anyone else have the same issues? I’d really like to get this fixed. Thanks!
Hello i have same issue with asterisk 11.4 and sipml5 with Chrome and IE(webrtc4all 1.12.756).
When i use Chrome, i receive an error in asterisk:
[Aug 15 12:32:42] WARNING[17001][C-000000a8]: res_srtp.c:406 ast_srtp_unprotect: SRTP unprotect failed with: authentication failure 10
[Aug 15 12:32:44] WARNING[17001][C-000000a8]: res_srtp.c:406 ast_srtp_unprotect: SRTP unprotect failed with: authentication failure 110
Well I got that to work by patching asterisk in the 11.5. I can make calls using SIPML and WS without using webrtc2sip or any of the proxy gateways inside of SIPML5, but I cannot get the call to come off of hold on the SIPML side. If I put the call on hold from another SIP client it is fine, but if I hold the call using SIPML5 then the audio for the SIPml5 side will not come back when the call is taken off of hold. In addition if I try to resume the call while recording I get a ton of SRTP unprotect errors and no regnegotiated audio stream on either end.
Have you checked the SIPml5 issues too? Like code.google.com/p/sipml5/issues/detail?id=85
yea i did, they dont have any fix for it on there. I have been messing with the code for the past week trying to get it working but to no avail.
We are experiencing the same issue using sipml5 also with the previous Asterisk 11.2 release.
Hold does not work at all.
Also the sipml5 forum does not seem to have found a solution yet.
Anyone has any good news or suggestion?
Nope not at all. Its a issue with websockets itself. We have to wait for the browser vendor to fix the websocket issue because the packet gets lost in the browser itself.