Known info for getting SIP working

[kp]

Im hoping to offer this info to help people figure out what is going on after this recent update.

Known DNS queries:
911.talk4free.com
mls.softjoys.com
prov1.talk4free.com
render.talk4free.com


Known HTTP GET Requests:
/images/911/GreenLight.gif
/images/ClickHereToOrder_large.gif
/images/spacer.gif
/javascripts/magicJack.js
/location_picker.php?dbkey=(really long hash)&version=20090410000001&osname=Win
/msgs/ad_voicemail.html
/msgs/ad_voicemail_lg.jpg
/msgs/rotate2.html
/stylesheets/common.css
/stylesheets/custom.css

Current User Agent String (pulled from wireshark):
MagicJack/1.80.484a (SJ Labs)

If you have anything to add, please add it.

[mjsbz]

it also seems to fail everytime on the first attempt to authorize.

Yes. I know what you mean, wireshark says Not Authorized un all first attempts when using the USB dongle. As far as I can remember, it has always been like this.

[inet777]

I compared the SIP request/response for both MJ and X-lite. I noticed (among other things) that "Via" Message header (for successful registration through MJ dongle) contains a tring "branch=XXXXXXXXXXXXXXXXYYYYYYYYYYYYYYYY" (32 alphanumerics), where X is a constant, but Y keeps on changing every time. For unsuccessful registration my X-lite sent a branch string of 43 alphanumerics.

Further, I read that Via header cannot he set by application. So could this be a counterattack? Can somebody shed light on this?

[UncleRunkle]

Yes, you are correct about the unauthorized first attempt with the dongle. Below is a wireshark screenshot of the MagicJack's SIP packets when first connecting:

http://unclerunkle.googlepages.com/Wireshark_1.jpg

And here is my RTP300 router's requests which get denied:

http://unclerunkle.googlepages.com/Wireshark_2.jpg

Here is my current router configuration line 1 page:

http://unclerunkle.googlepages.com/Linksys.jpg

I have tried to mirror the magicjack packets as closely as I can, but I am in need of some help. First, I think we should try to get as close of a SIP packet as we can, and then we can explore other authentication such as via the web requests.

Also, I erased some identifying info in the printscreens, so if I missed anything PLEASE let me know!

[UncleRunkle]

I compared the SIP request/response for both MJ and X-lite. I noticed (among other things) that "Via" Message header (for successful registration through MJ dongle) contains a tring "branch=XXXXXXXXXXXXXXXXYYYYYYYYYYYYYYYY" (32 alphanumerics), where X is a constant, but Y keeps on changing every time. For unsuccessful registration my X-lite sent a branch string of 43 alphanumerics.

Further, I read that Via header cannot he set by application. So could this be a counterattack? Can somebody shed light on this?

You make a good point -

1st MagicJack connection
Via: SIP/2.0/UDP 192.168.81.128:50996;branch=z9hG4bKc0a8518004d1924f6edb541b0;rport

2nd MagicJack connection
Via: SIP/2.0/UDP 192.168.81.128:60046;branch=z9hG4bKc0a8518004fafd0844365d661;rport

3rd MagicJack connection
Via: SIP/2.0/UDP 192.168.81.128:61927;branch=z9hG4bKc0a85180072222f75dab56d71;rport

As you can see, for me it is z9hG4bKc0a851800 (16 characters) which stays the same.

Now, for my RTP300 connection, I get:
Via: SIP/2.0/UDP 192.168.0.234:61171;branch=z9hG4bK-a2b3e92a;rport

Only z9hG4bK (7 characters) is the same...what does this mean? Also, multiple connections with the RTP300 validate that it is only 7 characters that stay the same. Is the rest a serial number or something?

[inet777]

here is my hypothesis (not proven yet).

STEP 1: MJ dongle makes 1st SIp call to register, with branch # of 32 alphanumerics. First 16 are constant, secong 16 are tied to your dongle.

STEP 2: SIP server responds with a new branch id, as well as message Authorization failed.

STEP 3: Then MH dongle makes another SIP call, this time passing the branch id that server sent, and viola authorization successful (since now the Via header contains branch id that came from server in step 2 above).

Does this make sense? Thus only your MJ dongle can get authorized, unless you program exact same id in the VIA header.

[UncleRunkle]

here is my hypothesis (not proven yet).

STEP 1: MJ dongle makes 1st SIp call to register, with branch # of 32 alphanumerics. First 16 are constant, secong 16 are tied to your dongle.

STEP 2: SIP server responds with a new branch id, as well as message Authorization failed.

STEP 3: Then MH dongle makes another SIP call, this time passing the branch id that server sent, and viola authorization successful (since now the Via header contains branch id that came from server in step 2 above).

Does this make sense? Thus only your MJ dongle can get authorized, unless you program exact same id in the VIA header.

I can't say for sure, but I think you are wrong. The only difference between the first magicjack registration attempt and the 2nd is the different ending branch id and a new authorization line:

Authorization: Digest username="Exxxxxxxxxx01",realm="stratus.com",nonce="15f157f4c_09874",uri="sip:talk4free.com",response="cbc89c174162cdb305c44a41f5aea775",algorithm=MD5

In the auth denied packet from the proxy, I see no mention of a different branch id.

1st failed MJ reg attempt:
Via: SIP/2.0/UDP 192.168.81.128:60046;branch=z9hG4bKc0a8518004faf7b935e3657c0;rport

MJ auth denied reply
Via: SIP/2.0/UDP 192.168.81.128:60046;branch=z9hG4bKc0a8518004faf7b935e3657c0;rport=60218;received=xxx.xxx.xxx.xxx(my ext. ip)

[inet777]

What I am wondering is how does the branch id change between first call to proxy (unauthorized) and second call to proxy with a differnt branch id - which is authoprized by server. Clearly the last 16 digits for second (successful) call are different. Any ideas on how this branch id was generated?

[inet777]

Also, I saw the exact same Authorization tag in SIP header from X-lite client (with different nonce field). So I don't think Authorization tag makes any difference.

I am beginning to zero in on the branch field value as what makes authorization successful or not. It seems to me that the branch field value changes between first unsuccessful and subsequent succesful call to proxy. And that's what authorizes the request.[/quote]

[neo2121]

I was poking around with just trying to get xlite to reg....i found that I can get it to register if I use these settings.







But also I cant make any phone calls and I cant receive any as well this as expected. Just figured i would post this stuff not really any closer to making it work. But I think that the community will trial and error till we find the new settings. I'm on a laptop with out wire shark so i will update the post later

[kp]

Heres a captured registration for a MJ dongle


REGISTER sip:talk4free.com SIP/2.0
Via: SIP/2.0/UDP 10.0.2.15:59200;branch=z9hG4bK0a00020f02d6ae315fac24720;rport
From: "unknown" <sip:[email protected]>;tag=f4e2d6ae1d
To: <sip:[email protected]>
Contact: <sip:[email protected]:59200>
Call-ID: 23AE5EE12BC24156B952216150B763D70x0a00020f
CSeq: 1 REGISTER
Max-Forwards: 70
User-Agent: MagicJack/1.80.484a (SJ Labs)
Content-Length: 0
Supported: path

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.2.15:59200;branch=z9hG4bK0a00020f02d6ae315fac24720;rport=59193;received=xxx.xxx.xxx.xxx
To: <sip:[email protected]>
From: "unknown"<sip:[email protected]>;tag=f4e2d6ae1d
Call-ID: 23AE5EE12BC24156B952216150B763D70x0a00020f
CSeq: 1 REGISTER
User-Agent: ENSR2.5.47.0-IS30-RMRG0-RG900-EP1756539
WWW-Authenticate: Digest nonce="1ba5a10ed_00549",realm="stratus.com",algorithm=MD5
Content-Length: 0

REGISTER sip:talk4free.com SIP/2.0
Via: SIP/2.0/UDP 10.0.2.15:59200;branch=z9hG4bK0a00020f02d6b28829f27da51;rport
From: "unknown" <sip:[email protected]>;tag=f4e2d6ae1d
To: <sip:[email protected]>
Contact: <sip:[email protected]:59200>
Call-ID: 23AE5EE12BC24156B952216150B763D70x0a00020f
CSeq: 2 REGISTER
Max-Forwards: 70
User-Agent: MagicJack/1.80.484a (SJ Labs)
Authorization: Digest username="EXXXXXXXXXX01",realm="stratus.com",nonce="1ba5a10ed_00549",uri="sip:talk4free.com",response="1986ca37bb3fa8b9f0581dcf03e73562",algorithm=MD5
Content-Length: 0
Supported: path

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.2.15:59200;branch=z9hG4bK0a00020f02d6b28829f27da51;rport=59193;received=xxx.xxx.xxx.xxx
To: <sip:[email protected]>
From: "unknown"<sip:[email protected]>;tag=f4e2d6ae1d
Call-ID: 23AE5EE12BC24156B952216150B763D70x0a00020f
CSeq: 2 REGISTER
User-Agent: ENSR2.5.47.0-IS30-RMRG0-RG900-EP1756539
WWW-Authenticate: Digest nonce="19ae107cb_00594",realm="stratus.com",algorithm=MD5
Content-Length: 0

REGISTER sip:talk4free.com SIP/2.0
Via: SIP/2.0/UDP 10.0.2.15:59200;branch=z9hG4bK0a00020f02d6c53b00112a7f2;rport
From: "unknown" <sip:[email protected]>;tag=65e22d6c4cd
To: <sip:[email protected]>
Contact: <sip:[email protected]:59200>
Call-ID: 23AE5EE12BC24156B952216150B763D70x0a00020f
CSeq: 3 REGISTER
Max-Forwards: 70
User-Agent: MagicJack/1.80.484a (SJ Labs)
Content-Length: 0
Supported: path

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.2.15:59200;branch=z9hG4bK0a00020f02d6c53b00112a7f2;rport=59193;received=xxx.xxx.xxx.xxx
To: <sip:[email protected]>
From: "unknown"<sip:[email protected]>;tag=65e22d6c4cd
Call-ID: 23AE5EE12BC24156B952216150B763D70x0a00020f
CSeq: 3 REGISTER
User-Agent: ENSR2.5.47.0-IS30-RMRG0-RG900-EP1756539
WWW-Authenticate: Digest nonce="13df52f1a_00742",realm="stratus.com",algorithm=MD5
Content-Length: 0

REGISTER sip:talk4free.com SIP/2.0
Via: SIP/2.0/UDP 10.0.2.15:59200;branch=z9hG4bK0a00020f02d6c925672f48643;rport
From: "unknown" <sip:[email protected]>;tag=65e22d6c4cd
To: <sip:[email protected]>
Contact: <sip:[email protected]:59200>
Call-ID: 23AE5EE12BC24156B952216150B763D70x0a00020f
CSeq: 4 REGISTER
Max-Forwards: 70
User-Agent: MagicJack/1.80.484a (SJ Labs)
Authorization: Digest username="EXXXXXXXXXX01",realm="stratus.com",nonce="13df52f1a_00742",uri="sip:talk4free.com",response="ba289a3fe2cbe701e720f1605dbbb34d",algorithm=MD5
Content-Length: 0
Supported: path

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.2.15:59200;branch=z9hG4bK0a00020f02d6c925672f48643;rport=59193;received=xxx.xxx.xxx.xxx
Contact: <sip:[email protected]:59200>
To: <sip:[email protected]>;tag=72c8c37f-co770-INS030
From: "unknown"<sip:[email protected]>;tag=65e22d6c4cd
Call-ID: 23AE5EE12BC24156B952216150B763D70x0a00020f
CSeq: 4 REGISTER
Expires: 1800
User-Agent: ENSR2.5.47.0-IS30-RMRG0-RG900-EP1756539
Content-Length: 0

[UncleRunkle]

One more thing that I would like to point out,

before the MagicJack registers successfully the 2nd time (after the 1st unauthorized attempt) it does a dns query. It seems to do this consistently so I am wondering if that is in the equation as well.

DNS Standard query A mls.softjoys.com

and

DNS Standard query response CNAME map.softjoys.com A 69.4.236.236

Can anyone else verify that this always happens before MagicJack registers?

[youneeq]

softjoys is essentially SJ Labs. (see below.)

MJ's parent company, YMAX, owns SJ Labs, "the softphone factory". They make SJPhone rebranded as MagicJack or a lot of the code is based off SJPhone. There has already been some mention about it. Another link too. I think Vonage does something similar.

From Telephony Online article:
MagicJack’s parent company, YMax Voice Network, built and designed its own CLEC network for the service, relying on more than 50 switches and gateways – more than any other telecom company, according to Borislow – where its customers actually live. The company owns the network assets and has made acquisitions totaling $30 million. Despite the investment, Borislow said with the scale MagicJack has achieved to date, incremental growth is very inexpensive, and the company is poised for profitability this year.

YMax also acquired chip company TigerJet in 2008 and software company SJ Labs in 2007 to create more than 1.7 million lines of plug-and-play code for MagicJack. The six-patent owner also just acquired Stratus Telecom on Friday to provide the remaining pieces of the business before another competitor could. The company employs a team of 340: 100 people to assemble the product, 160 in customer service, 40 employees building software and 40 working on the network, corporate, media and sales.

“We own a chip company, software company and network company but didn’t own the glue that kept us all together,” Borislow said. “[With Stratus], we’ll be able to develop features and functions a lot faster, and we can sleep more comfortably knowing that a competitor won’t buy that company. We pretty much have complete control of every aspect of the business right now.”

One more thing that I would like to point out,

before the MagicJack registers successfully the 2nd time (after the 1st unauthorized attempt) it does a dns query. It seems to do this consistently so I am wondering if that is in the equation as well.

DNS Standard query A mls.softjoys.com

and

DNS Standard query response CNAME map.softjoys.com A 69.4.236.236

Can anyone else verify that this always happens before MagicJack registers?

[inet777]

OK, I am just getting handle on this counter measure. I do not want to get ahead of myself, but I appreciate the amount of time Dan has put in this counter measure. For shits and grins, I used sipp (sipp.sourceforge.net) as a starting point to replicate the traffic between my computer and MJ servers. Kept on modifying the scenarios (i.e. configure the uac xml files) and then I had some success in that area, I was able to replicate the expected behavior. I am going with a "sip proxy server of my own" solution. I think an average ATA user (who just configures and plugs his/her device) will not benefit from this solution. The solution is for advanced users (who run a mini data center i.e. smtp, http and sip servers on home computers). I think Dan's intention to introduce this counter measure is to have a speed breaker, not total elimination of ATAs. Over a period of time, many advanced users will gravitate towards the "sip proxy in the middle" type of solution. Over and out.

[jsherk]

Not sure if this article would be any help to anybody:
http://www.0xdecafbad.com/?p=140

[inet777]

Yes, as I had suspected almost 6 months ago; proxy in the middle solution is the most effective solution for this problem. I personally use MJMD5 and it is working flawlessly since June. But nice to know that there are other solutions. I think we are due for another counter measure from Dan.