mike's blog

Super techy post today.

We ran down a problem where a Grandstream phone had two users (Lisa and Michele) registered. Both users were in the same call group so the Grandstream phone received two calls that were nearly identical. The difference was the two calls designated two different call branches and were to different usernames, but both reflected the same call-ID (because they ARE the same call, just separate branches.)

After some work, we discovered that the Grandstream phone rang the line of the first SIP INVITE it received, but 'answered' the last INVITE. Following through the trail of INVITEs and CANCELs below, you can see where the confusion starts. We have submitted this information to Grandstream for their consideration - we are asking that their devices honor the "branch" tag.

For those SIP tech's out there, enjoy our analysis of a call to two users on the same SIP UA (all phone numbers, domains and IP addresses have been modified):

Two users in group Lisa and Michele

Lisa is on 192.168.1.107:5060 on a Grandstream - this phone receives Branch .2.
Michele is also on 192.168.1.107 but on port 5064 on a Grandstream - this phone receives Branch .5.

Customer reports that this call was picked up by the "Lisa" line.

**Invite to Lisa on Grandstream (GS) - Branch .2. of call ID 133...3a4c**
U 2009/05/08 09:40:18.325507 66.227.1xx.2xx:5060 -> 24.33.2xx.3xx:5060
INVITE sip:lisa@192.168.1.107:5060;transport=udp;aor=lisa%40xxuserdomainxx.onsip.com SIP/2.0.
Record-Route: .
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKd146.d2c78147.2.
Via: SIP/2.0/UDP 66.227.100.215:5060;received=66.227.100.215;branch=z9hG4bK1a92f9f1;rport=5060.
From: "0000000000" ;tag=as2bbf1438.
To: .
Contact: .
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 69.
Date: Fri, 08 May 2009 13:40:18 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Content-Type: application/sdp.
Content-Length: 381.
P-Gateway: 66.227.100.215.
.
v=0.
o=root 26678 26678 IN IP4 66.227.100.215.
s=session.
c=IN IP4 66.227.100.215.
t=0 0.
m=audio 19870 RTP/AVP 0 8 3 111 18 4 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:111 G726-32/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:4 G723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.


**Invite to Michele on GS - Branch .5. of call ID 133...3a4c**
U 2009/05/08 09:40:18.325571 66.227.1xx.2xx:5060 -> 24.33.2xx.3xx:5064
INVITE sip:michele@192.168.1.107:5064;transport=udp;aor=michele%40xxuserdomainxx.onsip.com SIP/2.0.
Record-Route: .
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKd146.d2c78147.5.
Via: SIP/2.0/UDP 66.227.100.215:5060;received=66.227.100.215;branch=z9hG4bK1a92f9f1;rport=5060.
From: "0000000000" ;tag=as2bbf1438.
To: .
Contact: .
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 69.
Date: Fri, 08 May 2009 13:40:18 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Content-Type: application/sdp.
Content-Length: 381.
P-Gateway: 66.227.100.215.
.
v=0.
o=root 26678 26678 IN IP4 66.227.100.215.
s=session.
c=IN IP4 66.227.100.215.
t=0 0.
m=audio 19870 RTP/AVP 0 8 3 111 18 4 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:111 G726-32/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:4 G723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.

**Receive "Trying" from Lisa on GS - Branch .2.**
U 2009/05/08 09:40:18.404981 24.33.2xx.3xx:5060 -> 66.227.1xx.2xx:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKd146.d2c78147.2.
Via: SIP/2.0/UDP 66.227.100.215:5060;received=66.227.100.215;branch=z9hG4bK1a92f9f1;rport=5060.
From: "0000000000" ;tag=as2bbf1438.
To: .
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
CSeq: 102 INVITE.
User-Agent: Grandstream GXP2000 1.1.6.46.
Content-Length: 0.
.

**"RINGING" from Lisa on GS - Branch .2.**
U 2009/05/08 09:40:18.416313 24.33.2xx.3xx:5060 -> 66.227.1xx.2xx:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKd146.d2c78147.2.
Via: SIP/2.0/UDP 66.227.100.215:5060;received=66.227.100.215;branch=z9hG4bK1a92f9f1;rport=5060.
Record-Route: .
From: "0000000000" ;tag=as2bbf1438.
To: ;tag=b71cb81c3beef471.
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
CSeq: 102 INVITE.
User-Agent: Grandstream GXP2000 1.1.6.46.
Contact: .
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE.
Content-Length: 0.
.


** "RINGING" from Michele on GS - .5.  We did not receive "Trying" from the .5. branch, but that's not an issue.  However, customer reports that only one 'line' is ringing on the phone itself: the 'Lisa' line.**
U 2009/05/08 09:40:18.479063 24.33.2xx.3xx:5064 -> 66.227.1xx.2xx:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKd146.d2c78147.5.
Via: SIP/2.0/UDP 66.227.100.215:5060;received=66.227.100.215;branch=z9hG4bK1a92f9f1;rport=5060.
Record-Route: .
From: "0000000000" ;tag=as2bbf1438.
To: ;tag=b71cb81c3beef471.
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
CSeq: 102 INVITE.
User-Agent: Grandstream GXP2000 1.1.6.46.
Contact: .
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE.
Content-Length: 0.
.

**Status:  At this point we have received provisional responses on both branch .2. and branch .5., but the customer states that only one 'line' on the phone is ringing.

**OK from Lisa on Grandstream - NOTE:  The ok is from the user 'Lisa' BUT it's in response to the .5. branch.  This is a problem.  The .5. branch was the user 'Michele's branch.  Theory - the first invite received is the line that rings, but when answered, the phone answers the last invite received.**
U 2009/05/08 09:40:27.712967 24.33.2xx.3xx:5060 -> 66.227.1xx.2xx:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKd146.d2c78147.5.
Via: SIP/2.0/UDP 66.227.100.215:5060;received=66.227.100.215;branch=z9hG4bK1a92f9f1;rport=5060.
Record-Route: .
From: "0000000000" ;tag=as2bbf1438.
To: ;tag=b71cb81c3beef471.
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
CSeq: 102 INVITE.
User-Agent: Grandstream GXP2000 1.1.6.46.
Contact: .
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE.
Content-Type: application/sdp.
Supported: replaces, timer.
Content-Length: 213.
.
v=0.
o=lisa 8000 8000 IN IP4 192.168.1.107.
s=SIP Call.
c=IN IP4 192.168.1.107.
t=0 0.
m=audio 5056 RTP/AVP 0 101.
a=sendrecv.
a=rtpmap:0 PCMU/8000.
a=ptime:20.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11.

**Sending "CANCEL" to Lisa at the .2. branch**
U 2009/05/08 09:40:27.713409 66.227.1xx.2xx:5060 -> 24.33.2xx.3xx:5060
CANCEL sip:lisa@192.168.1.107:5060;transport=udp;aor=lisa%40xxuserdomainxx.onsip.com SIP/2.0.
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKd146.d2c78147.2.
From: "0000000000" ;tag=as2bbf1438.
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
To: .
CSeq: 102 CANCEL.
Max-Forwards: 70.
User-Agent: OpenSIPS (1.5.1-notls (x86_64/linux)).
Content-Length: 0.
.



**OK back from Lisa on GS regarding CANCEL - Branch .2.**
U 2009/05/08 09:40:27.784852 24.33.2xx.3xx:5060 -> 66.227.1xx.2xx:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKd146.d2c78147.2.
From: "0000000000" ;tag=as2bbf1438.
To: ;tag=b71cb81c3beef471.
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
CSeq: 102 CANCEL.
User-Agent: Grandstream GXP2000 1.1.6.46.
Supported: replaces, timer.
Content-Length: 0.
.

**Lisa user on GS saying Request Cancelled - however this shows branch .5. is being cancelled - the Grandstream previously gave an OK to the .5. branch in the OK above, now it's cancelling the call.  Basically it's confused between the branches.  The customer experience is that the call now drops.**
U 2009/05/08 09:40:27.793189 24.33.2xx.3xx:5060 -> 66.227.1xx.2xx:5060
SIP/2.0 487 Request Cancelled.
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKd146.d2c78147.5.
Via: SIP/2.0/UDP 66.227.100.215:5060;received=66.227.100.215;branch=z9hG4bK1a92f9f1;rport=5060.
Record-Route: .
From: "0000000000" ;tag=as2bbf1438.
To: ;tag=b71cb81c3beef471.
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
CSeq: 102 INVITE.
User-Agent: Grandstream GXP2000 1.1.6.46.
Content-Length: 0.
.


**Junction Networks ACK's the 'Request Cancelled" on the .5. branch in the above packet.**
U 2009/05/08 09:40:27.793432 66.227.1xx.2xx:5060 -> 24.33.2xx.3xx:5064
ACK sip:michele@192.168.1.107:5064;transport=udp;aor=michele%40xxuserdomainxx.onsip.com SIP/2.0.
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKd146.d2c78147.5.
From: "0000000000" ;tag=as2bbf1438.
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
To: ;tag=b71cb81c3beef471.
CSeq: 102 ACK.
Max-Forwards: 70.
User-Agent: OpenSIPS (1.5.1-notls (x86_64/linux)).
Content-Length: 0.
.


**Asterisk PBX sending "BYE" to user Lisa on GS for call - now that all other branches were cancelled, the call is now branch .0.**
U 2009/05/08 09:41:18.413797 66.227.1xx.2xx:5060 -> 24.33.2xx.3xx:5060
BYE sip:lisa@24.33.2xx.3xx:5060;transport=udp SIP/2.0.
Record-Route: .
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKe146.a562be32.0.
Via: SIP/2.0/UDP 66.227.100.215:5060;received=66.227.100.215;branch=z9hG4bK3f1ae941;rport=5060.
From: "0000000000" ;tag=as2bbf1438.
To: ;tag=b71cb81c3beef471.
Contact: .
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
CSeq: 103 BYE.
User-Agent: Asterisk PBX.
Max-Forwards: 69.
Content-Length: 0.
.

**Lisa on GS complaining that there is no such call to send the BYE to - that phone had already cancelled the call**
U 2009/05/08 09:41:18.480821 24.33.2xx.3xx:5060 -> 66.227.1xx.2xx:5060
SIP/2.0 481 No Such Call.
Via: SIP/2.0/UDP 66.227.1xx.2xx;branch=z9hG4bKe146.a562be32.0.
Via: SIP/2.0/UDP 66.227.100.215:5060;received=66.227.100.215;branch=z9hG4bK3f1ae941;rport=5060.
Record-Route: .
From: "0000000000" ;tag=as2bbf1438.
To: ;tag=b71cb81c3beef471.
Call-ID: 1330352b536b8d7a74970bcf4df83a4c@jnctn.net.
CSeq: 103 BYE.
User-Agent: Grandstream GXP2000 1.1.6.46.
Content-Length: 0.
.

We are currently tracking an inbound call completion issue with a limited number of DIDs. We will update this post in the comment section of the post.

Insecure Extension Passwords on Asterisk (VoIP PBXs)

Junction Networks has become aware of four separate hack attempts against our PSTN Gateway customers over the last few days. Three of these customers were Asterisk customers and one was another SIP-based VoIP PBX. After communicating with our customers, it appears that the hack has nothing to do with any sort of Asterisk vulnerability, but with insecure passwords set for extensions. This blog post captures the issue well. Blocking the offending IP addresses at the router level does not help as they will just continue the attack from another address.

The best solution is to create secure passwords for your extensions. The passwords that come with sip.conf must not be used:

;[polycom]
;type=friend             ; Friends place calls and receive calls
;context=from-sip        ; Context for incoming calls from this user
;secret=blahpoly
;host=dynamic            ; This peer register with us
;dtmfmode=rfc2833        ; Choices are inband, rfc2833, or info
;username=polly          ; Username to use in INVITE until peer registers
                         ; Normally you do NOT need to set this parameter
;disallow=all
;allow=ulaw              ; dtmfmode=inband only works with ulaw or alaw!
;progressinband=no       ; Polycom phones don't work properly with "never"

Instead of secret=blahpoly, we would recommend that the password be at least 12 characters. Here are some good sites for password generation:

PC Tools

GRC

Cut and paste the secure password into sip.conf and into the phone. Use a different password for each extension.

Additionally, we would recommend the above strong random passwords in conjunction with limiting the IP addresses extensions can connect from to particular networks. There is some documentation on how to do this in your sip.conf here: http://www.voip-info.org/wiki/view/Asterisk+sip+permit-deny-mask

If all of your phones are on the LAN, and your LAN is 192.168.0.0/24 the input would be:

;Deny every address except for the LAN.
deny=0.0.0.0/0.0.0.0
permit=192.168.0.0/255.255.255.0

From the asterisk-security mailing list, Olle Johansson, the maintainer of the Asterisk SIP module had this to say...

[asterisk-security] Person Trying to Register on my Asterisk multiple times
Johansson Olle E oej at edvina.net 
Fri Jan 23 15:51:46 CST 2009

...

Attacks are never fun. Use the ACL (permit/deny) in sip.conf to block this IP or range of IPs at least. 

Or use IPtables. There are a lot of IPtables scripts to prevent this kind of attacks if you look at the solutions for the very common SSH attacks that keep testing multiple usernames. Maybe someone on the list has a version for SIP attempts over TCP and/or UDP?

It's always good to have a bit less obvious peer names than the ones they test. Don't use usernames or extension numbers. Make sure you separate the namespaces. Kevin usually suggest Ethernet MAC addresses, which are harder to guess, but still relates to something even though they do have a well-known pattern.

Finally, it's important to make sure you have good passwords. There's no reason to have simple passwords in something you only install in software in devices or applications. There's no user who has to learn to remember the MD5 auth secrets.

That's my 10 cents. Please, list, fill in and correct me when wrong!
/O

The big news today is the Skype announcement about supporting SIP for business users. With this launch, it appears Skype will have a product similar to the Junction Networks PSTN Gateway service. With a single Skype ID, an owner of a SIP-capable IP PBX will be able to leverage Skype's In and Out services, making and receiving calls to and from landlines and mobile phones. Calls to Skype users seem to be out of scope. As a long-time proponent of open standards, it is great to see Skype recognizing SIP as the de facto VoIP standard. However, this is just a pinkie toe dip into the ocean that is SIP.

1. Hosted PBX vs. IP PBX + PSTN Gateway
The first question I was asked today regarding this announcement was "Are you worried about Skype coming into the market?" My answer was an emphatic "No." Skype is a VoIP pioneer and powerhouse for consumers. Supporting SIP makes sense and confirms our recognition that SIP is the standard of today and the future. OnSIP customers have known this for some time and are leveraging the full capabilities of SIP while abandoning the PBX altogether. Skype’s new service requires a premises-based PBX system. We see lots of our own PSTN Gateway customers switching to our OnSIP Hosted PBX platform.

2. Capital Expenditures high for IP PBXs
The FierceVoIP article linked above states that 438,000 IP PBXes shipped in 2008. It's now 2009 and companies have a greatly reduced capital budget. With a Hosted PBX like the OnSIP customers save large amounts of money by avoiding a PBX purchase and ongoing total cost of ownership expenses related to management and upgrades of a PBX.

3. Easy setup with Hosted PBX
With a Hosted PBX all the configuration is done online via a WWW interface. We had a customer last week who had to literally abandon their PBX because it crashed and the original technician had long since left the company. No one knew how to restart it or even where it was physically located. With the OnSIP hosted solution, that is never even close to a problem.

4. SMBs need Technical Support
SMBs need technical support. For many SMBs the "tech" person is also the accountant, the receptionist and/or the owner. It is rare when a SMB has dedicated technical staff. Connecting to the myriad VoIP PBX brands out there is no easy feat. Asterisk is clearly dominant, but there's 3CX, Avaya, Nortel and Cisco just to name a few. Each PBX handles the little things like DTMF and "Early Media" a little differently. Those are all lessons we've learned over the last five years that Skype will just now have the pleasure of exploring.

5. SIP is the way
Junction Networks has always allowed free SIP calling. Hopefully this SIP gateway will mean that Skype customers will have a SIP address that's reachable from the outside. Our vision has always been that SIP will create a perfect storm of inexpensive (if not free) communications options for businesses. SIP is the promise of that future and Skype seems to have caught on.

Right now the product is available as closed beta (by invitation only). Hopefully it will stick around.

The LA Times is reporting that cell phone users are being charged, on average, $3.02 per MINUTE of cell phone use. They arrive at that figure by taking the number of minutes charged vs. the number of minutes actually used. Basically, it comes down to an issue of trying to predict something that is nearly unpredictable - the exact number of cell phone minutes you will use NEXT month. This number seemed high to me, so I looked at my own cell phone bill over the last two months. I'm not at $3 per minute, but I'm no where near even 10 cents per minute. I'm at just over a quarter ($0.26) per minute. And that's just taking the cost of my minutes divided by my minutes used. When you look at my entire phone bill, it's over 50 cents ($0.55) per minute.

Junction Networks does not force you to predict an ever changing future then lock you into it. With us, you only pay for the minutes you use. With Junction Networks, take the minutes used divided by your usage charge, and you will see exactly 2.9 cents ($0.029). That is a HUGE savings. It is literally an order of magnitude better than my cell phone bill and light years away from the LA Times study mentioned above.

When you pay for what you use, your phone bill is going to be slightly different from month to month. But in August, when everyone is on vacation and no one is using the phone, your phone bill will actually go DOWN for that month with Junction Networks. In these tough economic times, it should be more important to save on expenses than to have a phone bill that is the same from month to month.

TMC's blog pans the broadband stimulus package. Yes, Junction Networks is a technology company and yes, we would, in theory, benefit from comprehensive broadband access. However, I think that the post misses the point.

The post states: "I just don't think broadband is that vital that we need to spend billions of tax payer dollars when we are a fiscal crisis, the stock market is imploding, and the deficit is shooting through the roof." He goes on to say that only a few companies will be helped by spending on broadband. I disagree. Not only will a very wide range of existing companies be directly helped by widely available broadband, but a whole set of products and services run by new companies that don't even exist today will be created which will, in turn, create more jobs and opportunities for US citizens.

The best example I can think of is the addition of GPS functionality to mobile phones. Before my iPhone had GPS, I never considered what having an always-available GPS functionality really meant. Now, I can't believe I lived that long with out it. Broadband everywhere will have the same effect. We will have a hard time remembering a time when not everyone had broadband access everywhere. Today, my kids can't believe that when I grew up there was no Internet. Look at what the Internet has done for productivity and job creation in a relatively short time span. Hopefully, my grand-kids will be just as shocked that their parents only had broadband access at home and not every home had broadband. One can only hope.

Here is a little hint about what product Junction Networks is writing about this week for our OnSIP Hosted PBX:

Hopefully none of our customers use our product to do this.

Stay tuned for the blog post later this week. We're putting the finishing touches on it now.

Thank you.

To our customers, friends and fans: Thank you. The Small Business Computing Magazine's 'Excellence in Technology 2008' award was selected entirely by its readers, and Junction Networks and our OnSIP Hosted PBX won in the VoIP category. Thank you for voting for us.

Winning an award like this when faced with such incredible competition from the likes of Microsoft and others shows that a small, highly-focused group of people can make a great product at a great price that absolutely fills a business need. In business, you rarely get the Big Game feeling of hoisting the trophy over your head in victory, but wins like this are pretty close.

Our press release is here.

Junction Networks is currently working on an issue with the ACD servers. They should be back online shortly. We apologize for the inconvenience. We will update this entry in the comments section.

Users are unable to log into an ACD queue. However, no calls are being lost. All calls are rolling over to the 'failover location' for the queue, which, in most cases, is a voicemail box.

Once service is restored, all ACD users must re-login to their respective queue(s).

1/27/2009 - Happy Birthday Lewis Carroll

'Twas billing, and the DTMF tones
Did ping and poke in the net
All mimsy were the landline phones
And those iLEC customers upset.

"Beware the iLEC, my son!
The dinosaur with rates so high!
Beware the H323 and shun
The codec near to neigh.

He took his SIP phone in hand;
Long time the LandLine foe he sought--
So rested he by the INVITE tree,
And stood awhile in thought.

And as in uffish thought he stood
The iLEC, with bills so long
Came dialing through the wire-strewn wood,
And pulse dialed as it came!

One, two! One, two! and through and through
The OnSIP blade went snicker-snack!
He left it dead, and with its head
He went un-SUBSCRIBING back.

"And has thou slain the iLEC?
Come to my network, my SIPish boy!
O frabjous day! U-law and A-!"
He chortled in his joy.

'Twas billing, and the DTMF tones
Did ping and poke in the net
All mimsy were the landline phones
And those iLEC customers upset.