latest checkout has issues with sofia-sip stack

[bhakimi]

when i register a sip client i get this error

nta: bind(XXX.XXX.XXX.XXX:*;transport=*): Protocol not supported
nua: initializing SIP stack failed

[bhakimi]

here is more debug info

[janus.c:janus_ws_handler:701] Done getting payload, we can answer
{"janus":"message","body":{"request":"register","username":"sip:128@XXX.XXX.XXX.XXX","secret":"password"},"transaction":"oCPVNNlJSyE4"}
[1476096338] There's a message for JANUS SIP plugin
{
   "request": "register",
   "username": "sip:128@XXX.XXX.XXX.XXX",
   "secret": "password"
}
Creating plugin result...
Destroying plugin result...
[janus.c:janus_ws_request_completed:2930] Request completed, freeing data
Handling message: {
   "request": "register",
   "username": "sip:128@XXX.XXX.XXX.XXX",
   "secret": "password"
}
Registering user sip:128@XXX.XXX.XXX.XXX (secret password) @ XXX.XXX.XXX.XXX through (null)
Joining sofia loop thread (128)...
Setting up sofia stack (sip:128@XXX.XXX.XXX.XXX)
nta: bind(XXX.XXX.XXX.XXX:*;transport=*): Protocol not supported
nua: initializing SIP stack failed
[ERR] [plugins/janus_sip.c:janus_sip_handler:1187] Two seconds passed and still no NUA, problems with the thread?
Pushing event: {
   "sip": "event",
   "error_code": 499,
   "error": "Two seconds passed and still no NUA, problems with the thread?"
}
[1476096338] Adding event to queue of messages...
  >> 0 (Success)
We have a message to serve...
        {
   "janus": "event",
   "session_id": 533647822,
   "sender": 1476096338,
   "transaction": "oCPVNNlJSyE4",
   "plugindata": {
      "plugin": "janus.plugin.sip",
      "data": {
         "sip": "event",
         "error_code": 499,
         "error": "Two seconds passed and still no NUA, problems with the thread?"
      }
   }
}

[saghul]

What sofia-sip version did you install? On Nov 10, 2015 03:51, "bhakimi" notifications@github.com wrote:

here is more debug info

[janus.c:janus_ws_handler:701] Done getting payload, we can answer {"janus":"message","body":{"request":"register","username":"sip:128@XXX.XXX.XXX.XXX","secret":"password"},"transaction":"oCPVNNlJSyE4"} [1476096338] There's a message for JANUS SIP plugin { "request": "register", "username": "sip:128@XXX.XXX.XXX.XXX", "secret": "password" } Creating plugin result... Destroying plugin result... [janus.c:janus_ws_requestcompleted:2930] Request completed, freeing data Handling message: { "request": "register", "username": "sip:128@XXX.XXX.XXX.XXX", "secret": "password" } Registering user sip:128@XXX.XXX.XXX.XXX (secret password) @ 208.78.138.35 through (null) Joining sofia loop thread (128)... Setting up sofia stack (sip:128@XXX.XXX.XXX.XXX) nta: bind(208.78.138.103:;transport=_): Protocol not supported nua: initializing SIP stack failed [ERR] [plugins/janus_sip.c:janus_sip_handler:1187] Two seconds passed and still no NUA, problems with the thread? Pushing event: { "sip": "event", "error_code": 499, "error": "Two seconds passed and still no NUA, problems with the thread?" } [1476096338] Adding event to queue of messages...

0 (Success) We have a message to serve... { "janus": "event", "session_id": 533647822, "sender": 1476096338, "transaction": "oCPVNNlJSyE4", "plugindata": { "plugin": "janus.plugin.sip", "data": { "sip": "event", "error_code": 499, "error": "Two seconds passed and still no NUA, problems with the thread?" } } }

— Reply to this email directly or view it on GitHub https://github.com/meetecho/janus-gateway/issues/375#issuecomment-155266727 .

[bhakimi]

1.12.11, i even tried 1.12.10 and the same issue

[lminiero]

Why do you think it's an issue with the latest checkout? The only changes made recently to the SIP plugin have nothing to do with the SIP stack. Have you checked if a previous version of Janus works fine instead? If so, which one started to give you problems?

[bhakimi]

sorry i was just stating which checkout i was using, not that its the latest that caused this. i tried one from 2 month ago and it has the same issue. i compiled everything from source. i wonder if any of the dependencies require a specific version. is it possible for me to give you ssh access and we can look at it together? i installed this on a gentoo box so all code is compiled from source

[MichaelB76]

@bhakimi - Are you compiling the Sofia code yourself? I'm not sure if it's related to your issue but there is a patch required when compiling Sofia with gcc 4.8:

https://code.google.com/p/unimrcp/issues/detail?id=169

Alternatively you can compile with the -fno-aggressive-loop-optimizations option. Without this some SIP messages were being corrupted. We found we could register but couldn't process the invite message.

[lminiero]

@MichaelB76 interesting info, thanks for sharing! Especially regarding the corrupted messages: I wonder if that's what was causing #293 for the user who reported it, for instance.

[bhakimi]

@MichaelB76 yea im compiling sofia from code since in gentoo all packages are compiled from source. i applied the patch and still have the same issue. im using gcc version 4.9.3

[bhakimi]

@MichaelB76 what should i compile -fno-aggressive-loop-optimizations with?

[bhakimi]

i even used freeswitches sofia-sip code base and i still have the same issue.

[bhakimi]

btw my issue is that i cant register

[bhakimi]

compiled sofiia-sip and janus with gcc version 4.7.4 and i still have the same issue

[saghul]

FWIW, here is the patch Debian applies: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729301#32

I have not had any problems with Sofia on Debian, using the provided packages.

[bhakimi]

i compiled sofia-sip with that flag and the patch but i still experience the same issue. im not too sure if this is a sofia-sip issue

[lminiero]

I don't see how this can be an issue in Janus if this works for everybody else except you... It's quite likely a Sofia-SIP issue in your specific setup. I'll look for some sample applications using Sofia-SIP that you can try and execute in your environment for further checking.

[lminiero]

It looks like there are several test applications provided as part of the Sofia-SIP code, in the tests folder. Have you tried building those as well, together with the stack, and giving them a try to see if those work for you instead?

[MichaelB76]

@bhakimi - That compiler flag is just for compiling Sofia, we didn't use it for Janus or any other dependencies. It sounds like a change to optimisations in GCC 4.8 showed up a bug in the Sofia code that previously had no effect.

Not sure what to suggest really but what SIP client are you using, and have you tried a different one? I notice the first error in the log is "protocol not supported".

[bhakimi]

I'm using the Janus sip demo client from your website On Nov 16, 2015 1:45 AM, "Michael Bennett" notifications@github.com wrote:

@bhakimi https://github.com/bhakimi - That compiler flag is just for compiling Sofia, we didn't use it for Janus or any other dependencies. It sounds like a change to optimisations in GCC 4.8 showed up a bug in the Sofia code that previously had no effect.

not sure what to suggest really but what SIP client are you using, and have you tried a different one? I notice the first error in the log is "protocol not supported".

— Reply to this email directly or view it on GitHub https://github.com/meetecho/janus-gateway/issues/375#issuecomment-156971829 .

20950 Warner Center Lane, Building A | Woodland Hills | California | 91367 Phone: 888-456-5454 | Fax: 888-401-7809 Web: www.safesoftsolutions.com

[bhakimi]

@MichaelB76 i see a test folder in the source but im unsure how to compile or even use it. i compiled sofia with gcc 4.7.4 and i still have the same issue.

UPDATE: had to run make valcheck to test it and no errors running different torture tests

[bhakimi]

@lminiero any progress on getting the professional support contract going so i can have you guys take a look at this? thank you =)

[lminiero]

Apparently the issue was passing NUTAG_SIPS_URL(sips_url) to nua_create: https://github.com/meetecho/janus-gateway/blob/master/plugins/janus_sip.c#L2459

This makes me wonder whether we can make SIP and SIPS transports configurations optional and configurable in the "register" request, so that you can always choose if you want both (which is currently the default and, as seen, can cause problems) or just one of them.

[saghul]

How is that a problem? That was required for TLS support IIRC. Can you elaborate on the steps to reproduce the issue?

[lminiero]

I have no idea how to reproduce that, actually :smile:

It's definitely happening on @bhakimi 's server, which is a Gentoo with a manually installed Sofia-SIP, so it may be an issue with how the library builds in that environment, or an issue with how Sofia SIP uses the security libraries there. I basically went through the Sofia-SIP code to check what may lead to that error, and tried to isolate the cause.

[saghul]

Oh! You can create an account in sip2ip.info and register over TLS by using sips:proxy.sipthor.net:443 as the outbound proxy in the demo app. Works For Me (TM).

[lminiero]

Yep, I know it works, but in his case he wasn't even trying to register a SIPS account. He was registering a plain SIP address, which failed when creating the NUA, probably due to a mishap in the SIP stack itself. That's why I'm wondering if we should actually only register exactly what's asked for in the "register" request, e.g., if the URI provided there is sip: use NUTAG_URL, if it's sips: use NUTAG_SIPS_URL. I'm not familiar enough with Sofia SIP to know whether or not that would work, though. Why did we put both there at the time? Is it because NUTAG_SIPS_URL is just an "addon" and still requires NUTAG_URL to be present?

In general nua_create should not fail, but in case it does and you're not interested in SIPS, that's why I was thinking of making the usage of NUTAG_SIPS_URL dependant on your actual need for it. If you think this makes sense I can work on a patch.

[saghul]

The whole idea of having to support both is braindead, IMHO. It should be smart enough to figure it out from DNS, but there are some problems, sadly.

I ended up doing the resolution outside and passing some "sips:1.2.3.4:443" like thing to it.

So, I guess we could do what you say, just enable one required. I have no time to make a PR these days, but if you make one, please @ me there so I don't miss it. Thanks!

[lminiero]

No problem, I can do that! What do you suggest as a trigger for adding NUTAG_SIPS_URL? Trying to register a sips account, or simply an additional attribute like sips:true|false, with sips=true being an implicit default? I guess the latter would be easier to integrate, would keep the working behaviour we had so far for who needed that, and still allow those not interested in it to skip that if they want.

[lminiero]

Just created a quick PR, which adds a new boolean "sips" attribute you can add to "register". The default value is still true, which means that normally it behaves exactly as it did before.

[bhakimi]

i dont know why im having such a hard time. i downloaded and compiled the latest git repo and im still having the same issue, i commented out NUTAG_SIPS_URL in the jnaus sip plugin, after that it was able to register but i was not able to place a call.

here is the error i got

Going to negotiate audio...
Allocating audio ports:
Audio RTP listener bound to port 21612
Audio RTCP listener bound to port 21613
Setting local audio port: 21612
Pushing event: {
   "sip": "event",
   "result": {
      "event": "calling"
   }
}
[1712578975] Sending event to transport...
  >> 0 (Success)
nta outgoing create: invalid URI
[128][nua_r_invite]: 900 Internal error at nua_client.c:711
[128][nua_i_state]: 900 Internal error at nua_client.c:711
Pushing event: {
   "sip": "event",
   "result": {
      "event": "hangup",
      "code": 900,
      "reason": "Internal error at nua_client.c:711"
   }
}
[1712578975] Sending event to transport...
  >> 0 (Success)
[1712578975] Plugin asked to hangup PeerConnection: sending alert
[1712578975] ICE loop exists but is not running, waiting for it to run
Sending WebSocket message (84 bytes)...
  -- Sent 84/84 bytes
Sending WebSocket message (284 bytes)...
  -- Sent 284/284 bytes
Sending WebSocket message (368 bytes)...
  -- Sent 368/368 bytes
[1712578975] Forcing ICE loop to quit (running)
[128][nua_i_terminated]: 900 Internal error at nua_client.c:711
[1712578975] ICE thread ended!
[1712578975] WebRTC resources freed
[128][nua_i_options]: 200 OK
[128][nua_i_error]: 500 Responding to a Non-Existing Request
[WSS-0x6f0898000b30] Got 74 bytes:
Got a Janus API request from janus.transport.websockets (0x6f08980127f0)

[lminiero]

Can you look for where /* Send INVITE */ is in the code, and before that add this line and do a new make + make install?

JANUS_LOG(LOG_WARN, "Prepared SDP:\n%s\n", sdp);

I want to check whether the SDP that is prepared for the SIP INVITE has anything weird that may be confusing the stack. It would be cool if you could also print the values of session->account.identity, uri_text and session->account.proxy as they're passed to nua_invite as well (if those values are sensitive for any reason send them privately to me).

[bhakimi]

@lminiero here is the output of those variables:

[WARN] Prepared SDP:
v=0
o=- 229130226138503249 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 50328 RTP/AVP 111 103 104 9 0 8 106 105 13 126
c=IN IP4 208.78.138.103
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=sendrecv

[WARN] uri_text :
sip:123@208.78.138.35
[WARN] session->account.identity :
sip:128@208.78.138.35
[WARN] session->account.proxy :
(null)

this should have all the variables you asked for, hope it helps

[bhakimi]

@lminiero

ok, compiling sofia-sip with gcc fixed the call issue, but in order to get the register to work i had to disable this line:

//TAG_IF(session->account.sips, NUTAG_SIPS_URL(sips_url)),

any ideas how we can permanently fix this so i dont have to mantain this?

thank you

[lminiero]

Don't comment the line: you can disable it passing an additional "sips":false attribute when sending the "register" request. Il 25/nov/2015 19:10, "bhakimi" notifications@github.com ha scritto:

@lminiero https://github.com/lminiero

ok, compiling sofia-sip with gcc fixed the call issue, but in order to get the register to work i had to disable this line:

//TAG_IF(session->account.sips, NUTAG_SIPS_URL(sips_url)),

any ideas how we can permanently fix this so i dont have to mantain this?

thank you

— Reply to this email directly or view it on GitHub https://github.com/meetecho/janus-gateway/issues/375#issuecomment-159690924 .

[bhakimi]

@lminiero sorry can you give me a full example of a registration uri and how it would look like?

right now i use something like this, sip:123@XXX.XXX.XXX.XXX

would i have to do sip:123@XXX.XXX.XXX.XXX;sips:false ?

[lminiero]

I'm talking of the Janus API request, not SIP directly. Here's an example of how you register from the demo:

https://github.com/meetecho/janus-gateway/blob/master/html/siptest.js#L455

Adding a register["sips"] = true; results in a { "request":"register", "username":"...", "proxy": "...", ..., "sips": false } message to the SIP plugin. The sips=false thing disables the tag.

[lminiero]

Closing as the issue has been fixed.

[bhakimi]

thank you

[saghul]

Thanks for getting to the bottom of this, folks!

On Thursday, November 26, 2015, bhakimi notifications@github.com wrote:

thank you

— Reply to this email directly or view it on GitHub https://github.com/meetecho/janus-gateway/issues/375#issuecomment-159781833 .

/Saúl bettercallsaghul.com