Interop with FreeSWITCH's "NDLB-connectile-dysfunction"

[Destreyf]

When trying to place a call to the soft client via WSS, FreeSWITCH reports "NORMAL_TEMPORARY_FAILURE"

the lines look like this
68c1c893-62c2-4035-823c-c19b90232960 2014-08-17 10:47:50.066431 [NOTICE] sofia.c:7286 Hangup sofia/internal/sip:[email protected]:57566 [CS_CONSUME_MEDIA] [NORMAL_TEMPORARY_FAILURE]

I can call a regular sip client just fine, and even using SipML5 (which we had been previously using) works without issues.

This is also affecting presence subscriptions (no messages are seen).

Changing over to WS, calls and presence both start working.

I would attach JS SIP Traces and wiresharks, but JS SIP traces never show a call attempt, and because its HTTPS/WSS wire shark is pretty much useless (unless someone knows how to decrypt the streams).

What testing has been done against WSS, am i missing something that could potentially be killing me?

Unfortunately using WS is not really an option because you cannot connect to WS from HTTPS due to security restrictions.

Outbound calling works flawlessly on both WS and WSS.

In the mean time, i will start investigating the code to see if i can generate any sort of output.

[egreenmachine]

Can you include SIP.js logs with traceSip turned on? Please include the successful outbound call and the failing inbound call logs. You can put the logs on http://pastie.org/ so as to not clutter this issue. Feel free to remove any sensitive information such as IP addresses and user/passwords.

For FreeSWITCH, what is the commit hash of the version of FreeSWITCH you are using? Can you also include more complete FreeSWITCH logs? How do your configs differ from the sample configs in our FreeSWITCH guide?

[Destreyf]

SIP.js initial startup: http://pastie.org/private/9ctxg7npjf0v47u67nb5g
SIP.js outbound call: http://pastie.org/private/pnr8vtozrml5xnxaecpqtw
SIP.js incoming produced nothing

FreeSWITCH incoming Log Part 1: http://pastie.org/private/kcurj6fkbie0tmvsg05n7q
FreeSWITCH incoming Log Part 2: http://pastie.org/private/nptnwn1puzgrvslpdhev2g

FreeSWITCH GIT hash:
root@fax:/usr/src/freeswitch-master# git show
commit 571cf932dcaa9db96125f2f5a7dcba83d0825bba
Author: Jeff Lenk [email protected]
Date: Sat Aug 16 18:22:41 2014 -0500

Currently updating FreeSWITCH to see if there's any impact/change of behavior.

Outgoing calls work flawlessly, Incoming are problematic ONLY when using WSS (Secure WebSockets). If i revert back to WS (Normal WebSockets) Inbound/Outbound calls work as expected.

What appears to be happening is that SIP.js is not responding to anything being sent to it through WSS, unless it started it, when i switch back to WS, i see that FreeSWITCH sends an Options packet trying to probe for information, where as WSS i do not see this behavior.

This is running against a build of SIP.js that was done a couple of hours ago.

Here's a copy of my internal profile: http://pastie.org/private/976qjj2cz4mdlav35dv1w

The users are generated dynamic by LUA, although this shouldn't matter as this same box worked with our last testing done with it.

Doing more investigations on my end.

[Destreyf]

Just want to follow up, testing on version:

FreeSWITCH Version 1.5.14b+git20140820T195046Z5f6db1db3e~64bit (git 5f6db1d 2014-08-20 19:50:46Z 64bit)

GIT HASH
root@fax:/usr/src/freeswitch-master# git show
commit 5f6db1db3ed16d3383dc566eb070a3b956065d70
Author: Nathan Neulinger [email protected]
Date: Wed Aug 20 14:50:46 2014 -0500

mod_skinny: roll back, these are not expected to be null terminated, they are fixed length

Still same issue, going to get SipML5 to verify its functioning.

[Destreyf]

Initially i had started to feel like this was an issue in FreeSWITCH, but i just used sipml5.org/call.html to make/receive on the same server and it worked flawlessly.

Is there anything else i can get you guys in an attempt to troubleshoot this?

[egreenmachine]

Trying to narrow down the issue, can you include clean FreeSWITCH logs for just the failing call case. To clarify the failing scenario.

Softphone <- UDP -> FreeSWITCH <- WSS -> SIP.js
--------------------->Invite
                  NORMAL_TEMPORARY_FAILURE

Nothing ever gets sent to SIP.js.

[Destreyf]

That's what I was seeing. Seeing as the only client having any trouble is
the one using sip.js I am uncertain of the cause.

I will be back to my computer in a few hours and will post more logs.
Hopefully we can sort this out as I do not want to go back to SipML5.

[egreenmachine]

WS/WSS are at the transport layer. If you can connect and register on WSS you should be able to make and receive calls (You did not include SIP.js logs for WSS so we cannot confirm this). From your FreeSWITCH logs, the 503 (NORMAL_TEMPORARY_FAILURE) is being thrown from the sofia layer. You could turn up sofia logging to see why it is doing that but I do not think it would help. Sofia is unaware of the transport layer used by FreeSWITCH.

[Destreyf]

The first log "Initial Startup" contains the registration/startup portion of the logs, the reason they were broken down like this is because pastie.org only allows 64KB pastes, and i was easily generating 50-75KB logs for each action.

I am currently testing to make sure there's not some parameter configured that's causing me grief and wasting your time, i will have more information shortly.

[egreenmachine]

https://gist.github.com/ might be better (1MB limit we think).

[Destreyf]

Just so that you guys have it

https://gist.github.com/Destreyf/66bff97f5c2e54074281

I haven't omitted anything in it.

6 separate files in that gist.

SIP.js WSS Registering/Inbound Call
SIP.js WSS Outbound Call
SIP.js WS Registering/Inbound Call
SIP.js WS Outbound Call
FS Inbound Call
FS Outbound Call

[Destreyf]

Edit: Ignore this... I'm seeing a Notify packet on WSS and an Options packet on WS.

Just an update, i mistakingly mentioned options packet not being seen, it is seen on both WS and WSS. However...

On WS SIP.js replies
Thu Aug 21 2014 14:45:02 GMT-0600 (Mountain Daylight Time) | sip.transport | sending WebSocket message:

SIP/2.0 200 OK

On WSS SIP.js replies
Thu Aug 21 2014 14:46:21 GMT-0600 (Mountain Standard Time) | sip.transport | sending WebSocket message:

SIP/2.0 405 Method Not Allowed

This might be causing FreeSWITCH to assume that the endpoint is inaccessible, and dropping communication attempts to it.

[Destreyf]

I have setup a test box that's a basic FreeSWITCH installation with a very basic client on it, with only WS and WSS enabled, and a valid SSL cert added onto the box.

I have it setup where you guys can log into the box, but the web interface is located here:

http://sipjs.simplitalk.com/index.html <- First Client
http://sipjs.simplitalk.com/index2.html <- Second Client

users are extension 1000-1009
passwords are 1234

This box does not go anywhere other than itself, its a 100% default setup (other than WSS and Cert info)

If you would like, i can give you SSH access to this box, with full read/write access to the FreeSWITCH and Web Files.

[egreenmachine]

Can you provide SIP logs of the Options packet succeeding and failing.

[Destreyf]

After some modifications were made to FreeSWITCH on the testing server, its suddenly working on that server, currently evaluating what changed to see if i can come to a resolution, i will update with more information and it'd be good to have noted on the documentation.

[Destreyf]

After troubleshooting some of the log files, what i found to be the culprit is this line.

<variable name="sip-force-contact" value="NDLB-connectile-dysfunction"/>

in my user, which is used to handle devices that handle NAT poorly, and I deal with multiple types of devices, something in the way that SipML5 must be making it work even with that enabled, however i will begin testing to see if we can remove this line from our configurations as i'm not convinced that this should be needed still.

If i end up bored like i was with the Hold Music issue I'll see if i can't figure out how to address this from the client end, but seeing as this is a feature in FreeSWITCH designed to handle old, unrelated hardware, i will go ahead and close this issue.

Thank you for your time, and I apologize for opening an issue without more testing in place than i had. Its very difficult to troubleshoot small things like this when using an older library was able to work.

[egreenmachine]

I will look into that option on our FreeSWITCH box and see if we can reproduce it and come up with a fix next week.

[wakamoleguy]

This one sounds out of scope for a SIP.js-side solution. Can we update our docs to indicate that we may be incompatible with this FreeSWITCH option?

[Destreyf]

@wakamoleguy This only affects extensions that have this variable/parameter set on the user. So if the user was configured without it, things would be fine.

With that said, i will stress this again, SipML5 does not have issues when using this option, which leads me to believe something might be wrong in either parsing or parameters sent with the registration causing an incorrect contact, for now i am not using WSS for my application, but we would like to implement it ASAP as we're security focused and need to keep as much data encrypted as possible.

We will be resuming development on our soft client in December, if during that time we find a resolution on either end i will update this issue, however i do think it'd be wise to document that there are incompatibilities as of now with WSS + Sip.js

[egreenmachine]

I have updated our FreeSWITCH guide with this new information.

[wakamoleguy]

We will be resuming development on our soft client in December, if during that time we find a resolution on either end i will update this issue...
Has anything come out of that?

[Destreyf]

@wakamoleguy

We had to push development off a little bit, we've resumed it just recently but we don't have any time slated for looking into this.

I did some very basic tests and didn't get anywhere. We want to address this once we have some more time available as we're going to be advertising it as highly secure, and it'll be our main push for people who don't want to buy hardware phones.

[emiliorcueto]

This interests me as well and I've started looking into it.

Very preliminary dive points to the default case in the switch statement checking the method var within the UA.prototype.receiveRequest method.

https://github.com/onsip/SIP.js/blob/master/src/UA.js#L710

I'll be digging in at some point this week and let you know what I find

[davidnamango]

For anyone still experiencing issues with this setting in FreeSWITCH as I was, if you set

hackWssInTransport: true

in your ua configuration then you will be able to successfully make inbound and outbound calls with wss.

This workaround does make it so you cannot make inbound calls (calls to the soft client) using ws however; which is opposite of the original issue of not being able to make inbound calls with wss. As wss is more secure anyways I see this as an okay tradeoff as you can just enforce wss to always be used.

I've done minimal testing on this, but I will report back if I find any issues.

[egreenmachine]

My conclusion at the moment is that we are not compatible with FreeSWITCH NDLB (no device left behind). This is turned on or off based on the individual user registering and should be off by default. The purpose of the option in FreeSWITCH is to support devices that have bad behavior with certain headers and params or for networks with NAT problems etc. Since SIP.js is establishing a socket based connection to FreeSWITCH and SIP.js correctly deals with SIP headers no NDLB options should be required. To make SIP.js behave correctly NDLB would be a backwards move. I am going to close this issue, but if there are more questions definitely feel free to continue this thread.