No remote audio for inbound call

[conrad.ja...@gmail.com]

I'm using SIPjs 0.7.5 with Chrome Version 50.0 Lastest for both i guess.

The WebRTC connects to a live server so its not double natted.

I'm able to make a call perfectly fine, but when i receive a call it does not playback the Audio revived as from the callers microphone (like from a cellphone).

Odd thing, this works fine in Firefox. And in Chrome at chrome://webrtc-internals/ I can clearly see bytes coming in:

googActiveConnection true
bytesReceived 47721 <---- I'm getting bytes in
bytesSent 66744
packetsSent 999
googReadable true
googChannelId Channel-audio-1
googLocalAddress 192.168.1.179:56778
localCandidateId Cand-jiij2hhA
googLocalCandidateType local
googRemoteAddress XXXX(SERVERIP)XX:45336
remoteCandidateId Cand-OzjQan2n
googRemoteCandidateType local
googRtt 15
packetsDiscardedOnSend 0
googTransportType udp
googWritable true

Also i can see the AUDIO object getting its src attribute applied when the call starts:

<audio id="remoteAudio" autoplay="" controls="" src="blob:https%3A//myserver.url.local/38b1f613-7361-49af-8a94-4b98c4e08dbd"></audio>

My audio from the PC's microphone to the remote side is perfect (sent audio). And again, both audio sides work if I establish the call from the WebRTC side.

Any idea's?

[James Criscuolo]

Hi,

  This could be any number of things, but there is more investigative work you can do. By calling getRemoteStreams on the session, then checking the tracks on those to make sure they are enabled and not muted, you can make sure the tracks are at least correctly set up (although I think you're webrtc internals output suggests that). From there, I would attempt to re-render, as you may be adding the stream to the element too early. I believe we use `onAddStream` to determine when to add it, but that has been deprecated for `onAddTrack` which is more likely to be helpful here. Regardless, re-rendering the stream a few seconds after everything has "settled" should let you know if that is the situation.

These are the two most common ways I get to the bottom of these issues. If neither works, we can explore further options.

Thanks,

James

[conrad.ja...@gmail.com]

I was just looking at that. But found only something called the "default" stream using session.getRemoteStreams(). And that was empty (no audio).

Let me give it some kind of stream management, after the accept. Will let you know.

[conrad.ja...@gmail.com]

Ok, this is what i have now discovered over a lengthily weekend dig-around.

The fact that this all works fine in FF means that the logic of the code works fine.

I got video-to-video calling working correctly! with two video stream and two audio streams - by setting up a different "call" button that sets up a call with full video constraints.

I think i need to fiddle a bit more as the video stream was terrible... only got about 3-4 seconds of video every 1-2 minutes.

Anyway, after the video calling worked, I played around with the different <audio> and <video> objects and it turns out that I can replicate the issue outbound by doing something similar in reverse. If I set a <video> object as the "remote:" item of an outbound audio call - i also don't hear the remote party. So it seems that if you are going to make a video call, then you must use a <video> object, and if you are making a audio call you must use an <audio> object. (Outbound)

This doesn't solve inbound tho... The problem seems to be in turning that around in the inbound call. I then setup two buttons, "Answer Audio" and "Answer video", and with these two buttons, im now able to make and answer a video call, but when it comes to a audio call, I still cannot hear the remote party.

So this works:
[WebRTC] <===> {internet} <===> [OpenSIPS (with RTPengine)] <===> [Asterisk] <===> {Carrier network} <===> [Cellphone]

This does not:
[Cellphone] <===> {Carrier network} <===> [Asterisk] <===> [OpenSIPS (with RTPengine)] <===> {internet} <===> [WebRTC]

I have tried answering the inbound audio call with a <video> object, but that didn't work either - same result, no inbound audio.

The inbound call was a voice only call, so is there something conflicting about that?
I remember reading somewhere that Chrome don't support audio only, or something to that effect. is that true?
Is that what's going on there? is there a workaround - like some fake video that i can introduce?

For the success of this project, our call center agents, are required to answer regular analog calls via WebRTC.

Btw, I tried to render() the stream, i tried everything i could - the "correct" stream/track does seem like its applied to the media element - even a few seconds after the call starts, i can clearly see:

enabled : true
id : "defaulta0"
kind : "audio"
label : "defaulta0"
muted : false
onended : null
onmute : null
onunmute : null
readyState : "live"
remote : true

[conrad.ja...@gmail.com]

After hours of testing I finally have the answer, but its complicated and it's not the code... It seems like its to do with logic.

To fix the problem all I did was disable the video codec on Asterisk for that extension. It then works correctly!

Ok, so this is what I found out. I looked closer at the the INVITE, and noticed that the offer has both audio and video always. So when i took a look at the attachMediaStream i noticed it was firing twice for an audio call inbound... and only once for an outbound call. So what's been happening is when you make a call you correctly constrain the media to audio only, but when you receive a call, even tho you set audio only constraints you still get an INVITE that has the audio and video markers. Now it appears that you cannot give a audio&video stream to an <audio> object and just get it to play the audio track, and also cannot get an audio&video track to play on the <video> object of no video packets actually get send down the stream.

So basically the fix was to never offer video in the INVITE, so then it plays it back with an audio object.

In Chrome:
1) It doesn't seem that the <audio> object can play the audio only track of a audio&video stream.
2) It doesn't seem that a audio&video stream will start playing if one of the streams never gets packets.

I also tried NOT attaching the video stream "defaultv0" to the element, but attaching the "defaulta0" stream to the audio element - but that did not work either for some reason. They seem linked somehow. Especially if the offer has video. It seems that it synced, or something?? don't know.

[Sebastian Gutierrez]

this is not a library issue is an asterisk issue:

https://issues.asterisk.org/jira/browse/ASTERISK-26050?filter=11340

please comment there if you think is the same issue.

[Lavkush Tyagi]

Hey I am new to SIP. i am using SIP.JS to make a call. the call is being made successfully but there is no audio on both side please help i attached my js code 
const USERNAME = "00000000";
const PASSWORD = "111111111";

const ua = new SIP.UA({
    password: PASSWORD,
    uri: `sip:${USERNAME}@111.com`,
    transportOptions: {
        wsServers: ["wss://111.com"]
    }
});

let session;

const dial = number => {
    debugger
    var Number = $("#txtphn").val();
    try {
        debugger
        var audioContext = new (window.AudioContext || window.webkitAudioContext)();
        var silentStream = audioContext.createMediaStreamDestination().stream;
        session = ua.invite(`sip:${Number}@111.com`, {
            sessionDescriptionHandlerOptions: {
                forceTURN: true,
                constraints: { audio: true, video: false },
                media: {

                    stream: audioContext,
                    render: {
                        remote: {
                            audio: document.getElementById('remoteAudio')
                        }
                    }
                }
            }
        });

        document.getElementById('btncall').style.display = 'none';
        document.getElementById('btnreject').style.display = 'inline-block';
    } catch (error) {
        console.error(error);
        return;
    }
   
    
const hangup = () => {
    if (session) {
        document.getElementById('btncall').style.display = 'inline-block';
        document.getElementById('btnreject').style.display = 'none';
        session.terminate();
    }
};