Audio issues on iOS prevent using JsSIP to initiate calls

[pjkundert]

Has anyone investigated where JsSIP fails, on iOS devices?

It seems to connect the websocket, register successfully with the SIP server, but when UA.call is invoked, it doesn't seem to ever send the SIP INVITE.

Probably some audio handling issue (which is quite a bit more complex and restricted on iOS than even on macOS browsers).

[pjkundert]

Some intriguing possible causes are found here by @Qvadis some years ago:

#616

[pjkundert]

OK, so part one of the issue was this:

iOS will refuse to allow Javascript code to access navigator. In RTCSession.js, when we call

return navigator.mediaDevices.getUserMedia(mediaConstraints)

the navigator.mediaDevices is undefined -- unless you're accessing the code in a "secure context": via https://... or file:///

This is not checked, causing an exception -- except since the exception is not thrown by the call itself, but by the code, it trickles down to the final .catch((error) =>, which neither logs nor re-throws the Error, it just swallows it.

I'll submit an Issue and a Pull for this, of course, but there are a couple of other things, too...

[ibc]

except since the exception is not thrown by the call itself, but by the code, it trickles down to the final .catch((error) =>, which neither logs nor re-throws the Error, it just swallows it.

What does "by the code" mean?

[AravindBollabathini]

Has anyone investigated where JsSIP fails, on iOS devices?

It seems to connect the websocket, register successfully with the SIP server, but when UA.call is invoked, it doesn't seem to ever send the SIP INVITE.

Probably some audio handling issue (which is quite a bit more complex and restricted on iOS than even on macOS browsers).

May be there will be an error as Bad Media Description as some of the streams that we are trying to get may not support in Mac.
Recently I got this issue and fixed in my code by changing the methods of retrieving the local and remote streams.

[tantonj]

Did you get this working on iOS Web Browsers? What methods/properties did you adjust? For me it seems my newRTCSession event fires, but no other event fires afterwards until I terminate the session. Works fine on Android/Windows.

[wnke]

Is this issue related to #604 ? Is particular this comment:

JSSIP does not work on mobile devices iOS. Safari or Chrome or another browser it does not matter, because all browsers on Apple mobile devices use same Webkit.

Is there any possible work around here?

[tantonj]

Has anyone found a work around for this? Surely some people have sip calls working in iOS web browsers. Do other libraries have this working? (SIP.js)

[hthetiot]

I have it works on iOS since couple of years now.

You may want to try adding this as it solved some issues for me.

            // https://askcodez.com/comment-le-controle-de-la-bande-passante-dans-webrtc-appel-video.html
            // https://stackoverflow.com/questions/29936416/webrtc-disable-all-audio-processing
            const disableinBandFEC = (data: { sdp: string }) => {
                if (data && data.sdp) {
                    data.sdp = data.sdp.replace('useinbandfec=1', 'cbr=1');
                }
            }

            session.on('sdp', (event: any) => {
                //console.debug('sip:sdp', event);
                //prioritizeH264(event);
                disableinBandFEC(event);
            });

If I have a moment I may provide a sample call code that works on iOS, if you provide one yourself it may help me to spot the other differences.

[hthetiot]

The proof that it works on iOS 18 with iosrtc sample properly configured with this video, larsen prove also WebRTC and good latency.

20250401_154834.mp4

[tantonj]

My findings with the provided javascript are as follows, this is not a request for any action on your part, nor an expectation of any response, and I am grateful for the help you have given thus far.

After modifying the code to work as a utils file for vue with my local only freeswitch/turn server I am able to connect the call in the same way I do my current implementation (browser on PC). However, after getting this working I had the 40 second delay on call connections due to ice gathering. So I updated the jsSipUrl to "https://jssip.net/download/releases/jssip-3.10.0.min.js" so that I could use the 'icecandidate' events and start the call in a timely manor.

The problem comes when I run this on iOS. The same behaviour I observed on my implementation occurs. The connecting event never fires. Please keep in mind that I do not have a mac to view the console on safari, so I've been working in chrome which gives a limited console. However, even when adding an alert('test'); in the connecting event I see it does not fire in safari.

Do you think this could have anything to do with my freeswitch/turn servers? Considering it simply isn't firing the connecting event I don't think it is. I should also note my wss ssl cert is self signed, but both browsers have it trusted.

The code I'm executing is strickly the TestRTCPeerConnection method which initiates a call with one of my network's sip devices. The implementation does not receive calls and it is audio only. I don't see any functional difference between the file you provided and my original implementation. A few extra parameters in the UA configuration which don't have any effect in my case (I've tried with my old config and the full set from the file). As well as using the older addstream instead of ontrack from the peerconnection. Clearly something is preventing connecting from occurring. I'm going to switch to the non-minified js and try debugging that, perhaps I'll find the root cause. (current test devices iPadOS Version 18.3.2 on 7th gen ipad, and iOS 18.4 iPhone 15 pro max)

[tantonj]

I have solved the problem and now have it working on iOS browsers. I had 2 problems, one which was only affecting development and what I spent most my time on, the other being a subtle difference between the 2 platforms which failed to initiate some specific code.

The actual problem
Turns out it was working the whole time, we just were not waiting long enough to have the call connect. The ice gathering was taking 40 seconds due to how my 'icecandidate' event triggers the ready() method. I was assuming that the best way to tell what the final ice candidate was would be to check if the protocol was "tcp". Turns out all ice candidates through iOS are under the udp protocol. For lack of a better way to tell when the final candidate is discovered I modified my event as follows:

'icecandidate': function (e) {
    if (e.candidate.protocol == 'tcp' || e.candidate.relatedAddress) {
        e.ready();
    }
}

I'm sure this will not be universal just as I expected when I originally wrote the "tcp" condition, but it works for my use case.
If anyone knows the proper way to tell when all icecandidates are found, I would greatly appreciate it.

What slowed me down
All my testing since the beginning of my first comment on this thread was using my vue app when running in debug mode on my workstation, there was no SSL cert. So once I debugged the JsSIP.js code I saw that the reason the connecting event never fired was because jssip crashed when calling navigator.mediaDevices.getUserMedia(mediaConstraints). This is because iOS requires a trusted ssl cert for this to function. After this I re-tested on my dev server and saw it did get passed the connecting event, and I noticed the ice candidates were also triggering. So I waited and sure enough the call eventually connected, leading me to find the actual problem.

[hthetiot]

Well done. I understand without mac and Safari remote debug it is hard.

Yes the ice delay is pain and lead to false positive, I may have a workaround, I will try to update jssip cordova-iosrtc-sample with it.

Thank you for your understanding to my replies.

[tantonj]

Just a note for anyone who comes across this problem in the future:
After I got the call connecting I realized I was not getting incoming audio.
On iOS the "addstream" event on the peerconnection would not fire. I switched back to the newer ontrack event. However, I had to change how to play the stream. The below code is how I did it.

this.activeSession.connection.ontrack = (e: any) => {
    //console.log("ontrack", e);
    var stream = new MediaStream();                           
    var audio = document.createElement('audio');
    audio.srcObject = stream;
    stream.addTrack(e.track);
    audio.play();
};

[qiulang]

@hthetiot I also had it worked on iOS couple of years ago but with iOS 18, I encounter the one-way audio on the call. I can not hear the other party, but they can hear me.

I have not figured out what the problem is.

Any idea ?

Thanks

[hthetiot]

Also read last reply here #860 (reply in thread)

[qiulang]

I finally figured it out! Just like @tantonj said "On iOS the "addstream" event on the peerconnection would not fire. I switched back to the newer ontrack event."

[qiulang]

Two months later safari has one-way audio again. I have not figured out why!

[hthetiot]

Two months later safari has one-way audio again. I have not figured out why!

Check this @qiulang, it works for many people using this sample:
https://github.com/cordova-rtc/cordova-plugin-iosrtc-sample/blob/6b75a940059e8c83c885cd6a52e456338a009dda/www/js/index-jssip.js#L292

[qiulang]

@hthetiot thanks for the reply. After further digging into the issue I find one-way audio happens in one of my of sip server but not in the other sip server (under the same network connection). But the strange thing is that these two sip server are basically the same.

✅ SDP is identical except the for the one-way audio, the sip server gets one a=ssrc:xxx msid:xxx message. But I remove this message from the client and it is still one-way audio.
✅ Network delivery works (bytes received)
✅ ICE connects successfully
✅ Safari receives ~82k bytes in 10 seconds
❌ But Safari doesn't play audio from one server
⚠️ No inbound-rtp stats available for both server

So I have to assume the problem is in the RTP packet content. I have not figured out the reason.