Sip transport candidates

[Mirko Brankovic]

Hi,

I was trying to call sip uri towards FreeSwitch, since I see on website that Asterisk is supported.

I'm not sure how asterisk is going it, but FS doesn't support trickeling ICE for now, so the problem is that the invite has no candidates in SDP and there for rtp will fail. 

I checked the siptest.js and saw that function doCall() has sipcall.send that will send the body and json to send invite, but the problem is that after that I see candidates gaithering, so this can be fixed on client side  I guess, to block sipcall.send untill the ICE is finished?

Thanks,

mirko

[Lorenzo Miniero]

No ICE is used on the SIP side in the SIP plugin, ICE is only used by Janus for WebRTC. SIP calls only have plain RTP negotiation (c-line and ports in m-line).

L.

[Mirko Brankovic]

Hey Lorenzo,

But how will the setup work without any candidate?

Right now in my test i get call set up correctly but after ack on 200 ok sip janus sends bye and call gets dropped:

and in janus.log i see these errors:

[Tue Nov  8 11:07:24 2016] [ERR] [plugins/janus_sip.c:janus_sip_relay_thread:3073] [SIP-1008] Error polling: POLLERR...
[Tue Nov  8 11:07:24 2016] [ERR] [plugins/janus_sip.c:janus_sip_relay_thread:3074] [SIP-1008]   -- 0 (Success)

I have attached the log also.

I'll see if the rtp starts flowing from any side now.

Can you take a look at the log, since  i can't find what might be wrong?

Thanks in advance,

Mirko

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

Mirko

[Lorenzo Miniero]

ICE is only needed between browser and Janus. Between Janus (SIP client on behalf of the browser) and Freeswitch it should not be needed, unless Freeswitch expects ICE there as well. The Janus SIP plugin is sending the BYE because of the "Error polling: POLLERR" error, as it assumes media is definitely broken. Try looking at the offer/answer between Janus and Freeswitch to see why that may be happening.

L.

[Mirko Brankovic]

Hi,

when I changed

diff --git a/plugins/janus_sip.c b/plugins/janus_sip.c
index ef78afc..b0c7ca7 100644
--- a/plugins/janus_sip.c
+++ b/plugins/janus_sip.c
@@ -3067,7 +3067,7 @@ static void *janus_sip_relay_thread(void *data) {
                        break;
                int i = 0;
                for(i=0; i<num; i++) {
-                       if(fds[i].revents & (POLLERR | POLLHUP)) {
+                       if(fds[i].revents & (POLLHUP)) {
                                /* Socket error? */
                                JANUS_LOG(LOG_ERR, "[SIP-%s] Error polling: %s...\n", session->account.username,
                                        fds[i].revents & POLLERR ? "POLLERR" : "POLLHUP");

to ignore POLLERR I got the RTP flow correctly between browser <> Janus <> FreeSwitch.

By examining the pcap, I would say that Pollerr appears because of the failed dtls srtp negotiation.

It could be that my FreeSwitch certs are old or pointing to not renewed Letsencrypt certs.

Let me check that and will report back :)

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,

Mirko

[Lorenzo Miniero]

There's no dtls between Janus and Freeswitch, as we only do dtls on the webrtc side, not the sip one. The cause of your issue is likely different.

L.

[Mirko Brankovic]

Just tested with RTP/SAVP:

   m=audio 12668 RTP/SAVP 111 103 104 9 0 8 106 105 13 126

and still the same, but negotiation is ok, FS reports that audio and video are ok:

2016-11-09 15:27:36.118983 [INFO] switch_rtp.c:3650 Activating Video Secure RTP SEND
2016-11-09 15:27:36.118983 [DEBUG] switch_core_sqldb.c:2612 Secure Type: srtp:sdes:AES_CM_128_HMAC_SHA1_80
2016-11-09 15:27:36.118983 [INFO] switch_rtp.c:3628 Activating Video Secure RTP RECV
2016-11-09 15:27:36.118983 [DEBUG] switch_core_sqldb.c:2612 Secure Type: srtp:sdes:AES_CM_128_HMAC_SHA1_80

I also tested call to Asterisk and that one worked out of the box, so this is really strange.

Maybe it is duo to fact that asterisk might be using  Symmetric RTP and SIP Comedia mode? maybe Janus is alpso expecting symetric traffic ?

Mirko

[Mirko Brankovic]

Hi Lorenzo,

Then I'm totally lost :)

Thanks :)

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,

Mirko

[Mirko Brankovic]

Is there a way I can find out why POLLERR is in events, mostlikely i'm hitting a timeout since FS might take a while to start sending RTP ?

[Lorenzo Miniero]

Currently traveling so not much I can do now, sorry. Try looking at the sdp offer/answer in sip to see if you spot anything weird.

L.

[Mirko Brankovic]

THe only thing I see is that I'm missing capabilities of stream:

a=sendrecv

if that is mandatory by Janus

Here is the asterisk vs freeswitch diff:

AST 200 OK:

v=0

o=root 1020302704 1020302704 IN IP4 **.**.**.**
s=Asterisk PBX 11.7.0~dfsg-1ubuntu1
c=IN IP4 **.**.**.**
b=CT:384
t=0 0
m=audio 13802 RTP/SAVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:fYdBfGaxw632PVF+XwI/MgocbcU9+fYyKFCOEbOn
m=video 19686 RTP/SAVP 107
a=rtpmap:107 H264/90000
a=fmtp:107 profile-level-id=42E01F;packetization-mode=1;level-asymmetry-allowed=1
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:AhNk4nDQcfI1AfGHt/uPWtErzxsp/kw47pwyTI3C

FS 200 OK:

v=0
o=FreeSWITCH 1478680803 1478680804 IN IP4 **.**.**.**
s=FreeSWITCH
c=IN IP4 **.**.**.**
t=0 0
m=audio 27432 RTP/SAVP 0 126 13
a=rtpmap:0 PCMU/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=rtpmap:13 CN/8000
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:Wn16/BtbyvtT5a73lPRPV7wYagueG4DxH3hX/XL8
m=video 22810 RTP/SAVP 107
b=AS:1024
a=rtpmap:107 H264/90000
a=fmtp:107 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtcp:22811 IN IP4 **.**.**.**
a=rtcp-fb:107 ccm fir
a=rtcp-fb:107 nack
a=rtcp-fb:107 nack pli
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:uvXTXSsSxEAE76VEGfDgSuze/fyrXl4bntw4kfRA

If sendrecv is not blocking, I'm not sure what is...