Janus SIP plugin hangs up

[Nitesh Bansal]

Hello,

For a certain specfic scenario, I noticed that Janus plugin just hangs up.
I'm trying to do an echo test for a SIP endpoint and in the middle of the call,
Janus SIP plugin stops responding, in the Janus logs, I see the following message

-------

[plugins/janus_sip.c:janus_sip_relay_thread:2883] [SIP-click2vox] Error polling: POLLERR.
-------

Additional info, I'm connected to Janus over websockets.
I'm registered as a guest, only piece of information, I'm supplying to it is username,
username is randomly set it 'sip:clic...@voxbone.com'
var register = {
                                "request" : "register",
                                "username" : "sip:clic...@voxbone.com",
                                "type" : "guest"
                        };
voxbone.WebRTC.sipplugin.send({"message": register});

Any ideas what could be wrong with the setup or Janus?

Thanks,
Nitesh

[Lorenzo Miniero]

POLLERR there means something goes wrong with the sockets that the call is using for sending/receiving RTP to/from the SIP user, making them unusable, and the only thing we can do is hangup the call. You should check what may be causing the problem with those file descriptors, and maybe adding some print lines that show the errno stuff associated with the error that occurred.

By the way, what do you mean by "the plugin stops responding"? The only thing that should happen after a POLLERR is the call being hang up, you should still be able to keep talking to the plugin to, for instance, start a new call on the same handle. If that's not happening (neither on the same handle nor on new handles on the same plugin) then it means some lock got messed up and it's a bug.

L.

[Nitesh Bansal]

Hi Lorenzo,

When I say, plugin stops responding, I mean that audio stream from remote SIP end point stops.
Actually, the SIP gateway I'm trying is an open echo test gateway, you could yourself try dialing the
following SIP URI 'sip:+8835100...@inum.net', the issue is reproducible on the SIP plugin demo
on your website too.
The strange thing is that call is all fine, I hear initial announcement, then it just stops in middle of announcement.

Nitesh

[Lorenzo Miniero]

I can't replicate it from home (the server seems to ignore my ACKs and keeps on sending me 200 OK over and over, so I never get to the call), but I could see it on the demo site, you're right. Not sure what's causing it, but I can see a bug: when POLLERR is detected, we're remaining in the loop instead of breaking it and hanging up the call as we should, I'll have to fix that. This won't fix your problem but will make the plugin behave as it should.

L.

[Nitesh Bansal]

Hi Lorenzo,

I looked at the SIP trace on port 5060, I get the impression that Janus isn't sending the ACK, that's why other end point is retransmitting the 200 OK.
And I still don't understand what triggers the polling error? But I do believe if we can sort the SIP signalling, it could work

Nitesh

On Friday, March 11, 2016 at 2:54:51 PM UTC+1, Nitesh Bansal wrote:

[Lorenzo Miniero]

Il giorno venerdì 11 marzo 2016 16:49:10 UTC+1, Nitesh Bansal ha scritto:

Hi Lorenzo,

I looked at the SIP trace on port 5060, I get the impression that Janus isn't sending the ACK, that's why other end point is retransmitting the 200 OK.
And I still don't understand what triggers the polling error? But I do believe if we can sort the SIP signalling, it could work

From the capture I did here at home I could see both the ACK and the 200 OK, I didn't do any capture on our demo website instead. In my case, though, the call was never started because of that: from what I understood, the call was started fine in your and the online demo's case, and something else happened. Not sure as to what's causing the POLLERR, as errno doesn't provide any additional info either: it just means the file descriptor is not usable anymore (maybe something closed it? the plugin itself somewhere else?). I'll have a look at this next week.

L.

[Nitesh Bansal]

In my case, call is started, media starts. SIP trace indicates that ACK was never sent.
My possible theory is following:
"Call starts, 200 OK received, media starts, but since we couldn't send the ACK, it is
possible that SIP plugin eventually tries to clear the SIP dialog on some timeout, I don't
know if there is a way to get more debug info from SIP plugin."

On Friday, March 11, 2016 at 2:54:51 PM UTC+1, Nitesh Bansal wrote:

[Lorenzo Miniero]

Not sure, as I did see the ACKs: I don't know if they were being sent to the right place, though. If you were following a specific "connection" (e.g., filtered in Wireshark) that may be why you didn't see any.

L.

[Nitesh Bansal]

I was following the traffic on port 5060 on Janus gateway.
If you think I could provide some extra information, please let me know.

Nitesh

On Friday, March 11, 2016 at 2:54:51 PM UTC+1, Nitesh Bansal wrote:

[Anand Sivaram]

Nitesh,

You are looking from the SIP Signaling angle on port 5060, but this poll error is happening on the RTP/RTCP sockets.

Assume you are on GNU/Linux based system, you could try the following.

* Log all file descriptors of socket/bind, close system calls inside janus_sip.c

* Use getsockname() after bind to find out the current value of the

  dynamic RTP/RTCP port (for using with next point)

* Use "netstat -aupn" to see that the actual RTP/RTCP port is still open.

* Use Wireshark to find all UDP traffic, ICMP port unreachable etc. 

Anand

[Lorenzo Miniero]

I'd capture SIP traffic in general: port 5060 may or may not be involved (Janus by itself definitely never binds to it).

L.

[Nitesh Bansal]

Hi,

I captured the SIP traffic and I think I have identified the call failure reason.
If you look at SIP 2xx response in my case; it contains the Record-route header
which is different from the Contact header address.
Janus is sending the ACK to the SIP address in the Contact header '81.201.82.41', where as it
should be sending it to the address in Record-Route header.
That being said, I don't  know why it gets into POLLERR?
Could you please help with these two issues?

On Friday, March 11, 2016 at 2:54:51 PM UTC+1, Nitesh Bansal wrote:

[Lorenzo Miniero]

That's a known issue with Sofia SIP, apparently: https://github.com/meetecho/janus-gateway/issues/451

As Saùl suggests in the comments, you probably have to resolve the address yourself and pass the IP as the proxy address.

L.

[Nitesh Bansal]

Ok, I added the proxy address and it worked.
But I don't really see it as a permanent solutions, I do believe that Sofia SIP supports record-route.

But it still leaves with another issue for 'POLLERR', do I need to create a bug report somewhere for that?

Nitesh

On Friday, March 11, 2016 at 2:54:51 PM UTC+1, Nitesh Bansal wrote:

[Lorenzo Miniero]

Il giorno lunedì 14 marzo 2016 11:57:38 UTC+1, Nitesh Bansal ha scritto:

Ok, I added the proxy address and it worked.
But I don't really see it as a permanent solutions, I do believe that Sofia SIP supports record-route.

By proxy address, I mean the user you register as a guest (e.g., sip:clic...@voxbone.com) should have the server part resolved (as in, don't pass voxbone.com, set the resolved IP address). Sofia SIP does support Record Route, but the problem is in the way it handles addresses. I'm not an expert in the library, and the comments to that issue I linked explain it in better detail.

 

But it still leaves with another issue for 'POLLERR', do I need to create a bug report somewhere for that?

Yes, please, create a new issue on github so that we can track it.

L.

[Lorenzo Miniero]

Il giorno lunedì 14 marzo 2016 12:01:11 UTC+1, Lorenzo Miniero ha scritto:

Il giorno lunedì 14 marzo 2016 11:57:38 UTC+1, Nitesh Bansal ha scritto:

Ok, I added the proxy address and it worked.
But I don't really see it as a permanent solutions, I do believe that Sofia SIP supports record-route.

By proxy address, I mean the user you register as a guest (e.g., sip:clic...@voxbone.com) should have the server part resolved (as in, don't pass voxbone.com, set the resolved IP address). Sofia SIP does support Record Route, but the problem is in the way it handles addresses. I'm not an expert in the library, and the comments to that issue I linked explain it in better detail.

Of course, if you're not registering as a guest, both the proxy and user part should have the same address resolved.

L.

[Nitesh Bansal]

There you go https://github.com/meetecho/janus-gateway/issues/484

Thanks,

Nitesh

On Friday, March 11, 2016 at 2:54:51 PM UTC+1, Nitesh Bansal wrote: