DTLS alert with SIP plugin

[Fabian Bernhard]

Dear list,

We are testing the SIP plugin and consistently receive a DTLS alerts after about 10 to 20 seconds in the audio session. We have tested with the official siptest.html and a Twilio audio conference room as the conference room provider.

http://pastebin.com/GXBzpBJy

The log is from an about a month old Janus commit compiled with OpenSSL. In the mean time we have also compiled the latest Janus commit against BoringSSL with the same results. This issue does not occur with the videoroom test, only with the SIP plugin. We therefore assume that the issue must be something specific to the SIP plugin.

Does anyone of you had similar issues which you were able to fix? 

Thanks for your assistance.

[Lorenzo Miniero]

I see this message:

[XXX][nua_i_bye]: 200 Session Terminated

which means it's the other end that is sending a BYE, which in turn results in the PeerConnection being torn down on the WebRTC side (alert).

L.

[Fabian Bernhard]

I see this message:

[XXX][nua_i_bye]: 200 Session Terminated

which means it's the other end that is sending a BYE, which in turn results in the PeerConnection being torn down on the WebRTC side (alert).

 

I have captured a TCP dump and indeed, Twilio sends the BYE. I have assumed that Janus sends the BYE due to the DTLS alerts because this works fine with a desktop SIP client. Must be something else that Twilio doesn't like, will investigate further.   

Thanks for your help!

 

[Fabian Bernhard]

[XXX][nua_i_bye]: 200 Session Terminated

which means it's the other end that is sending a BYE, which in turn results in the PeerConnection being torn down on the WebRTC side (alert).

 

I have captured a TCP dump and indeed, Twilio sends the BYE. I have assumed that Janus sends the BYE due to the DTLS alerts because this works fine with a desktop SIP client. Must be something else that Twilio doesn't like, will investigate further.   

After investigating further we found that the issue is related to this and not to DTLS:

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

Janus/SOFIA receives the 200OK but sends the ACK to the wrong route. I.e. the conference room never receives the ACK and thus hangs up after some time.

[Lorenzo Miniero]

That issue references a patch we added to handle that, though:

https://github.com/meetecho/janus-gateway/pull/490

That patch looks for the Route header and forces it, when enabled it there's a "Sending ack..." warning:

https://github.com/meetecho/janus-gateway/blob/master/plugins/janus_sip.c#L2425

that I do see in your log:

[33m[WARN] [0m Sending ACK (route=sip:54.172.60.2:5060;lr;ftag=FNSSpt82ZF8pF)

Isn't that the address that had to be contacted? Where was the SIP message sent instead?

L.

[Fabian Bernhard]

that I do see in your log:

[33m[WARN] [0m Sending ACK (route=sip:54.172.60.2:5060;lr;ftag=FNSSpt82ZF8pF)

Isn't that the address that had to be contacted? Where was the SIP message sent instead?

The 200OK was received from  54.172.60.2 (Twilio) through 91.121.78.130 (SIP proxy) -> Janus

The ACK was sent from Janus directly to 54.172.60.2, instead of the same route through the SIP proxy

[Lorenzo Miniero]

Yes, it was sent to sip:54.172.60.2:5060 because apparently there was a Route header saying so, I believe, which is exactly what the patch was added to do. Previously Janus would ignore Route headers, and so would send the ACK back to where it received the 200 OK from, instead of looking at the Route header. If you believe Janus is doing something wrong here, can you share the whole SIP transactions so that we can look into them?

Thanks,

Lorenzo

[Fabian Bernhard]

 If you believe Janus is doing something wrong here, can you share the whole SIP transactions so that we can look into them? 

http://pastebin.com/SphT3Ap6

Is there a way to configure the default outbound proxy? 

Thanks!

Regards,

Fabian

[Lorenzo Miniero]

I don't see any 54.172.60.2 address in those transactions, so not sure where to look.

I see two Record-Route headers in the 200 OK:

1. Record-Route: <sip:54.172.60.0:5060;lr;ftag=FXDgX6cUgyc5B>
2. Record-Route: <sip:91.121.78.130;lr;mr=yes>

and Janus is using the first one as the transport to contact for the ACK, as it's ostensibly the latest that has been added by the latest proxy who wants to be kept in the loop. Isn't that what it's supposed to do?

Does always setting "route" to NULL here fix it for you? https://github.com/meetecho/janus-gateway/blob/master/plugins/janus_sip.c#L2424

L.

[Fabian Bernhard]

I have reverted this change:

https://github.com/meetecho/janus-gateway/commit/7a6c85f639e22cd8c59b4878c79abc7f299a8af5

Now it works fine.

[Lorenzo Miniero]

Yeah, that's what I meant by setting the route value to NULL, which would have done the same thing (manual ACK but without overriding Route). At this point not sure what we should do in the plugin. Some say we were doing the right thing, others that we should override that. I guess the easiest way to handle this is to make it configurable via API, e.g., in the first REGISTER.

L.

[Fabian Bernhard]

Yeah, that's what I meant by setting the route value to NULL, which would have done the same thing (manual ACK but without overriding Route). At this point not sure what we should do in the plugin. Some say we were doing the right thing, others that we should override that. I guess the easiest way to handle this is to make it configurable via API, e.g., in the first REGISTER.

This would be a good idea, imho. And being able to configure the default behaviour in the plugin config file.

Thanks for your support!

[Lorenzo Miniero]

Done in this commit here: https://github.com/meetecho/janus-gateway/commit/1a4bc02f812349baa61536e9ad912b88dfbc8e5f

It adds a new "autoack" boolean property to call, which is TRUE by default: setting FALSE has Janus look at the Record-Route header to force sending NACKs there.

L.

[Fabian Bernhard]

Done in this commit here: https://github.com/meetecho/janus-gateway/commit/1a4bc02f812349baa61536e9ad912b88dfbc8e5f

It adds a new "autoack" boolean property to call, which is TRUE by default: setting FALSE has Janus look at the Record-Route header to force sending NACKs there.

Fantastic, thanks!