rfc2543 0.0.0.0 hold

[Mark Gooden]

Hi,

Our SIP platform currently uses the archaic rfc2543 hold method of setting the c address to 0.0.0.0 in the SDP in some circumstances.

One particular call scenario results in our SIP server sending JANUS an ACK SDP with c=0.0.0.0 which stems from an initial INVITE no SDP:

[Tue Jan 14 12:52:17 2020] This ACK contains a payload, probably as a result of an offerless INVITE: simulating 200 OK...
[Tue Jan 14 12:52:17 2020] Handling SDP answer in ACK
[Tue Jan 14 12:52:17 2020] Peer accepted our call:
v=0
o=xxxxx 77420 4 IN IP4 88.215.58.37
s=-
c=IN IP4 0.0.0.0

I would expect that JANUS at this point should stop sending RTCP to the SIP server, however instead it attempts to send RTCP to 0.0.0.0 (which is caught by loopback) and receives ICMP IP/port unreachable responses:

[Tue Jan 14 12:52:17 2020]  Error sending RTP audio packet... Connection refused (len=172, ts=2441019392, seq=15179)...
[Tue Jan 14 12:52:17 2020]  Error sending RTP audio packet... Connection refused (len=172, ts=2441019392, seq=15179)...

After 2 seconds of attempts it deems there have been too many errors and tears down the call:

[Tue Jan 14 12:52:19 2020] [ERR] [plugins/janus_sip.c:janus_sip_relay_thread:5952]  Too many errors polling 51 (socket #0): POLLERR...
[Tue Jan 14 12:52:19 2020] [ERR] [plugins/janus_sip.c:janus_sip_relay_thread:5953]  -- 111 (Connection refused)
[Tue Jan 14 12:52:19 2020] Call status change: [incall]-->[closing]

Not sure if this is a bug or whether there's some parameter that I'm missing that will prevent RTCP from being sent when JANUS receives 0.0.0.0 in an ACK SDP? I'm fairly new to JANUS still so still getting to grips with configuration etc. If you think this is a bug let me know and I'll raise an issue on github.

On another note, is there any way of increasing the time / number of errors from RTCP before JANUS tears down a call? Our SIP server is actually only injecting c=0.0.0.0 because this is a blind transfer scenario, and our SIP server does not yet know the transfer targets IP or port when it sends the ACK SDP. If we could increase this to say, 5 seconds or equivalent number of errors it would probably result in a successful blind transfer.

Thanks in advance
Mark

[Mark Gooden]

Managed to workaround this for now by adding another case for determining if the media session is on hold or not:

if(m->direction == JANUS_SDP_SENDONLY || m->direction == JANUS_SDP_INACTIVE || !strcmp(session->media.remote_audio_ip, "0.0.0.0"))
session->media.audio_send = FALSE;

Still, there's probably a more elegant solution out there..

[Lorenzo Miniero]

That does look like a good solution, actually, assuming the property is set to TRUE again once the address changes back to a valid one. If that works, would you prepare a PR? (and in case apply the same fix for video)

Lorenzo

[Mark Gooden]

So far everything seems okay, re-INVITES with valid IP's kick the audio session back into life again.

I've still got some further regression tests to do - If they continue to look good I'll arrange a PR (inc the same fix for video).

Cheers
Mark