We've been trying to get the Asterisk Cookbook going. It's the same format as other O'Reilly cookbooks - practical instructions for specific problems posted as recipes, just like a cookbook you'd use in the kitchen (at least that's what people usually do with them).
I haven't contributed much but I have an excuse - I don't really work with Asterisk that much anymore. So, a couple of days ago I asked the other authors and editors if we could widen the scope of the book to include some of my favorite technologies. Anyone that reads this blog knows what that means - Cisco, OpenSER, etc. I plan on writing quite a bit about OpenSER. As I said in my OpenSER book review, OpenSER needs more press and documentation. Let's work on that!
I've now contributed three recipes! My SIP DoS/DDoS mitigation script and a couple OpenSER scripts. Some of the OpenSER stuff is a little obscure and probably won't make it to the final book. I'll be adding more OpenSER, Cisco, and SIPp stuff over the next days/weeks/months. Keep checking here and there for updates.
Oh, and if you feel like you have something to add, get a hold of one of the authors (myself, Jim, Leif, Matt, Jared, etc) and we can figure out how to get you an account on the wiki.
Thursday, July 10, 2008
Book Review: Building Telephony Systems with OpenSER
I've been looking for and wondering about an OpenSER book for quite some time...
Everyone knows Asterisk is king when it comes to anything open source VoIP or telephony. OpenSER rocks but it just seems so, well, hardcore.
I can't imagine anyone walking into a Borders or Barnes and Noble, grabbing a book about OpenSER and cuddling up in one of those comfy, over-stuffed chairs on a rainy afternoon for some reading. Ok, I don't know anyone that does that anyway, and certainly not anyone with a book about OpenSER. I don't know about you but my tech books always end up getting rammed into my carry on for reading during "electronics prohibited" periods of air travel. That's all the time I care to dedicate to dead tree reads. But hey, it beats SkyMall (Jim Gaffigan: "Hey buddy, I work for SkyMall and I don't appreciate you jabbing us").
Bringing this back into focus (and on topic), is there a market for an OpenSER book? I've worked with two publishing companies in the past doing various amounts of writing and technical reviewing. Mostly O'Reilly but lately another company: Packt Publishing. Well, Packt decided there was a market for an OpenSER book and they decided to publish one. It's called Building Telephony Systems with OpenSER.
I found out about this book and knew I had to read it. What would an OpenSER book look like? What OpenSER features would be explored? What would it cost? What would it smell like? Ok, I'm just kidding about that last one but I was very interested.
I happened to be working on a couple of Packt Publishing projects at the time. I thought I'd contact one of my editors to see if they could hook me up. Turns out the book had already gone to press but they were willing to send me one. Cool!
Before I go any further I need to tell you: I won't be bought and I'm not easily influenced. Just because I've worked with Packt in the past doesn't mean I'm going to spare them any criticism or cut them any slack. If anything I'll go a little harder on them because they usually know how to get good authors and reviewers (me). ;) (Kidding, of course).
So they sent me a book. It's 295 pages and written by Flavio E. Goncalves. Flavio is a Brazilian that runs VoIP training in Brazil. Florianopolis, to be exact. Florianopolis is gorgeous. If you ever go to Brazil check it out. Hey, while you're there take an OpenSER training class from Flavio and get your company to pay for the whole thing!
Anyways, this is where my criticism starts to come in... I'm not one of these American English Nazis (does that make any sense?) that stands in line at the grocery store and freaks out when someone speaks Spanish or any other foreign language. However, I do believe that language exists as a mechanism to effectively communicate between people and sometimes that can be a little tricky even between two speakers of the same language. How many misunderstandings have you had with your friends, relatives, strangers etc while speaking the same language?
Brazilians speak Portuguese and I love it. It's one of the best sounding languages around. Being Brazilian, Flavio's first language is of course, Portuguese. It's also the language this book (Building Telephony Systems with OpenSER) was originally written in. My understanding from reading the book is that the book was developed out of Flavio's original (Portuguese) training course work and later translated to English. This makes for some very interesting and (sometimes) difficult to understand English language usage. There are several instances in the book that are difficult to follow because the language is, well, awkward. It looks like there was a proofreader... Maybe his style is different from mine but I'm pretty sure most people agree with me.
Part of me feels like this criticism is unfair and I wrestled with even mentioning it. Here's my chance to elaborate on this and explain myself.
Neither the author, editor, nor reviewers are native English language speakers yet this is what the book was written in. That's amazing to me. These people, in addition to being remarkably talented in their respective fields (publishing, technology) can all speak multiple languages and work on a team, around the world (India, Romania, Brazil) in a second language. The world is flat, my friend.
I feel like I can barely work and speak English half the time. Most Americans are the same way. We're all lazy, fat, SUV driving slobs that grunt back and forth in something that resembles English (which is already pretty "ugly"). Ok it's not that bad but that's what it's often made out to be... Anyone ever seen Idiocracy?
So for a technical book, my main criticism is English language usage and that's not even that bad. So far they're doing pretty well! On to the technical stuff...
I thought the book did a great job explaining the use of various OpenSER modules and OpenSER scripting in general. I also like how Flavio introduced readers to the various (relevant) SIP RFCs along the way. In working with OpenSER and SIP in general I can't stress how important this is. Many SIP platforms isolate you from the RFCs as much as possible. Everything is taken care of and it magically works (even with Asterisk when compared to OpenSER). With OpenSER this is not the case. You better know your RFCs. You better know the difference between components in a SIP network (Proxy, UAC, UAS, B2BUA, etc). You better know some core aspects of RFC3261 (stateful vs. stateless, strict routing, loose routing, methods, dialogs, domains, etc). Flavio isn't afraid to present this to the reader and he does it in a way that doesn't come across as snobby. Depending on the situation I've been known to quote RFCs and sections before. I probably (almost always) end up looking like a jerk but sometimes, hey, it needs to be done!
While reading I was disappointed to see so much focus on MediaProxy. I don't like MediaProxy. It's written in Python. Yuck. Enough said. I kept reading and by the end of the book Flavio admitted the mistake of more or less ignoring RTPProxy and agreed it was mostly superior. Bravo! No one knows everything, not even the guys that write the books. It was refreshing to see this in print. Once again, well done.
A couple of specific (nit picky) problems... The Asterisk config for a PSTN gateway on pg. 147 is suspect. The type doesn't make it clear which file you are working in and I doubt anyone would really use that SIP configuration in production. There's also no Zaptel config. I know this isn't an Asterisk book (there are plenty of those, the best one is free) but there should at least be a pointer to an online resource for Asterisk/Zaptel configuration or something.
The same thing goes for the Cisco config. If you look closely you'll see the dial-peer uses sip-notify for dtmf-relay. No one uses this and we certainly haven't configured OpenSER for it. Again, it's nit picky but some user could end up pulling all of his hair out trying to get this to work.
I didn't go over the OpenSER script bracket by bracket but it looked pretty good. That's even tougher to comment on because it's practically a programming language and no programmer ever completely loves the way someone else wrote something. That's just how it goes.
Overall, this is a very good book and it deserves to do well, for Flavio, everyone at Packt, OpenSER and the community in general. People who should be running OpenSER aren't. Hopefully this book can help change that!
Thank you to Flavio, the OpenSER team, and everyone at Packt Publishing!
Everyone knows Asterisk is king when it comes to anything open source VoIP or telephony. OpenSER rocks but it just seems so, well, hardcore.
I can't imagine anyone walking into a Borders or Barnes and Noble, grabbing a book about OpenSER and cuddling up in one of those comfy, over-stuffed chairs on a rainy afternoon for some reading. Ok, I don't know anyone that does that anyway, and certainly not anyone with a book about OpenSER. I don't know about you but my tech books always end up getting rammed into my carry on for reading during "electronics prohibited" periods of air travel. That's all the time I care to dedicate to dead tree reads. But hey, it beats SkyMall (Jim Gaffigan: "Hey buddy, I work for SkyMall and I don't appreciate you jabbing us").
Bringing this back into focus (and on topic), is there a market for an OpenSER book? I've worked with two publishing companies in the past doing various amounts of writing and technical reviewing. Mostly O'Reilly but lately another company: Packt Publishing. Well, Packt decided there was a market for an OpenSER book and they decided to publish one. It's called Building Telephony Systems with OpenSER.
I found out about this book and knew I had to read it. What would an OpenSER book look like? What OpenSER features would be explored? What would it cost? What would it smell like? Ok, I'm just kidding about that last one but I was very interested.
I happened to be working on a couple of Packt Publishing projects at the time. I thought I'd contact one of my editors to see if they could hook me up. Turns out the book had already gone to press but they were willing to send me one. Cool!
Before I go any further I need to tell you: I won't be bought and I'm not easily influenced. Just because I've worked with Packt in the past doesn't mean I'm going to spare them any criticism or cut them any slack. If anything I'll go a little harder on them because they usually know how to get good authors and reviewers (me). ;) (Kidding, of course).
So they sent me a book. It's 295 pages and written by Flavio E. Goncalves. Flavio is a Brazilian that runs VoIP training in Brazil. Florianopolis, to be exact. Florianopolis is gorgeous. If you ever go to Brazil check it out. Hey, while you're there take an OpenSER training class from Flavio and get your company to pay for the whole thing!
Anyways, this is where my criticism starts to come in... I'm not one of these American English Nazis (does that make any sense?) that stands in line at the grocery store and freaks out when someone speaks Spanish or any other foreign language. However, I do believe that language exists as a mechanism to effectively communicate between people and sometimes that can be a little tricky even between two speakers of the same language. How many misunderstandings have you had with your friends, relatives, strangers etc while speaking the same language?
Brazilians speak Portuguese and I love it. It's one of the best sounding languages around. Being Brazilian, Flavio's first language is of course, Portuguese. It's also the language this book (Building Telephony Systems with OpenSER) was originally written in. My understanding from reading the book is that the book was developed out of Flavio's original (Portuguese) training course work and later translated to English. This makes for some very interesting and (sometimes) difficult to understand English language usage. There are several instances in the book that are difficult to follow because the language is, well, awkward. It looks like there was a proofreader... Maybe his style is different from mine but I'm pretty sure most people agree with me.
Part of me feels like this criticism is unfair and I wrestled with even mentioning it. Here's my chance to elaborate on this and explain myself.
Neither the author, editor, nor reviewers are native English language speakers yet this is what the book was written in. That's amazing to me. These people, in addition to being remarkably talented in their respective fields (publishing, technology) can all speak multiple languages and work on a team, around the world (India, Romania, Brazil) in a second language. The world is flat, my friend.
I feel like I can barely work and speak English half the time. Most Americans are the same way. We're all lazy, fat, SUV driving slobs that grunt back and forth in something that resembles English (which is already pretty "ugly"). Ok it's not that bad but that's what it's often made out to be... Anyone ever seen Idiocracy?
So for a technical book, my main criticism is English language usage and that's not even that bad. So far they're doing pretty well! On to the technical stuff...
I thought the book did a great job explaining the use of various OpenSER modules and OpenSER scripting in general. I also like how Flavio introduced readers to the various (relevant) SIP RFCs along the way. In working with OpenSER and SIP in general I can't stress how important this is. Many SIP platforms isolate you from the RFCs as much as possible. Everything is taken care of and it magically works (even with Asterisk when compared to OpenSER). With OpenSER this is not the case. You better know your RFCs. You better know the difference between components in a SIP network (Proxy, UAC, UAS, B2BUA, etc). You better know some core aspects of RFC3261 (stateful vs. stateless, strict routing, loose routing, methods, dialogs, domains, etc). Flavio isn't afraid to present this to the reader and he does it in a way that doesn't come across as snobby. Depending on the situation I've been known to quote RFCs and sections before. I probably (almost always) end up looking like a jerk but sometimes, hey, it needs to be done!
While reading I was disappointed to see so much focus on MediaProxy. I don't like MediaProxy. It's written in Python. Yuck. Enough said. I kept reading and by the end of the book Flavio admitted the mistake of more or less ignoring RTPProxy and agreed it was mostly superior. Bravo! No one knows everything, not even the guys that write the books. It was refreshing to see this in print. Once again, well done.
A couple of specific (nit picky) problems... The Asterisk config for a PSTN gateway on pg. 147 is suspect. The type doesn't make it clear which file you are working in and I doubt anyone would really use that SIP configuration in production. There's also no Zaptel config. I know this isn't an Asterisk book (there are plenty of those, the best one is free) but there should at least be a pointer to an online resource for Asterisk/Zaptel configuration or something.
The same thing goes for the Cisco config. If you look closely you'll see the dial-peer uses sip-notify for dtmf-relay. No one uses this and we certainly haven't configured OpenSER for it. Again, it's nit picky but some user could end up pulling all of his hair out trying to get this to work.
I didn't go over the OpenSER script bracket by bracket but it looked pretty good. That's even tougher to comment on because it's practically a programming language and no programmer ever completely loves the way someone else wrote something. That's just how it goes.
Overall, this is a very good book and it deserves to do well, for Flavio, everyone at Packt, OpenSER and the community in general. People who should be running OpenSER aren't. Hopefully this book can help change that!
Thank you to Flavio, the OpenSER team, and everyone at Packt Publishing!
Monday, July 7, 2008
An update on SIP DoS mitigation
After spending a couple of hours on the VoIP User's Conference last week I thought I'd keep working on my SIP DoS/DDoS script a bit and get it to the point where I'd like to run it on some of my systems (if only to collect statistics).
The new version includes several new features, the most exciting (and certainly controversial) are changes to the string pattern matching for SIP requests. I now block ALL tel: URIs by default. I don't like tel: URIs. I think they're anti-SIP and you shouldn't use them. Now my script won't let you (unless you disable it, of course).
Anyways, I had to do this because (as I've already mentioned), I changed the way pattern matching runs on SIP requests. Two big changes:
1) Support a (configurable) offset for searches into the packet.
2) Update the SIP method matches to match "$METHOD sip:"
First of all, we now (by default) only search the first 65 bytes of the packet. That should be more than enough to search the first line for the SIP method and URI. Speaking of URI, I now match the URI along with the method to prevent false matches. Before we were only matching on the method and it was causing some false positives because of things like the Allow: header (where all of the supported methods are listed).
We'll see how this goes.
One thing I wanted to bring up in the VoIP User's call last week but failed to do so is the possible use of OpenSER to protect Asterisk (and other systems) from attack. In addition to supporting cool things like SIP message length filtering (msg:len) you can also use the pike module for some basic (but slightly more intelligent) SIP rate limiting. Of course then you need to support an OpenSER config, which a lot of people don't want to do...
What else is new in the script? Basic support for udp and/or tcp, configurable bursting, fixes to the FORWARD support and more. Check it out, it's free!
The new version includes several new features, the most exciting (and certainly controversial) are changes to the string pattern matching for SIP requests. I now block ALL tel: URIs by default. I don't like tel: URIs. I think they're anti-SIP and you shouldn't use them. Now my script won't let you (unless you disable it, of course).
Anyways, I had to do this because (as I've already mentioned), I changed the way pattern matching runs on SIP requests. Two big changes:
1) Support a (configurable) offset for searches into the packet.
2) Update the SIP method matches to match "$METHOD sip:"
First of all, we now (by default) only search the first 65 bytes of the packet. That should be more than enough to search the first line for the SIP method and URI. Speaking of URI, I now match the URI along with the method to prevent false matches. Before we were only matching on the method and it was causing some false positives because of things like the Allow: header (where all of the supported methods are listed).
We'll see how this goes.
One thing I wanted to bring up in the VoIP User's call last week but failed to do so is the possible use of OpenSER to protect Asterisk (and other systems) from attack. In addition to supporting cool things like SIP message length filtering (msg:len) you can also use the pike module for some basic (but slightly more intelligent) SIP rate limiting. Of course then you need to support an OpenSER config, which a lot of people don't want to do...
What else is new in the script? Basic support for udp and/or tcp, configurable bursting, fixes to the FORWARD support and more. Check it out, it's free!
Wednesday, July 2, 2008
SIP DoS/DDoS Mitigation
An interesting thread came up on Asterisk-Users the other day...
Someone had problems with some miscreant attempting (and apparently succeeding) to bruteforce a SIP account on his Asterisk system.
That's a problem. Asterisk currently has no means to protect against any type of SIP flooding/bruteforce/DoS (other than running out of resources/crashing). That's ok because some people (like myself) would argue that these types of attacks are best handled via other means...
Like the kernel, or preferably the kernel of a completely seperate box.
It got me to thinking - maybe I could whip up a script using some of the cool stuff in iptables/netfilter to mitigate these SIP DoS attacks in the kernel. I don't have a ton of time to elaborate on the script but for now here it is:
http://admin.star2star.com/sipdos
It's not great. It's not very SIP-specific. Who knows how accurate/effective/resource intensive it is. It hasn't been tested (much). For all I know, it will just make things worse. However, I think it is a step in the right direction and hopefully one of many tools that can be used to protect Asterisk and other SIP/VoIP systems.
By the way, I call it "SIP DoS Mitigation" because with any large enough DDoS attack, you are toast. ..
Speaking of other tools... We're all going to celebrate America's birthday this Friday by getting together on a conference call/IRC to talk over some of these issues with the VoIP User's Conference. Hear you there?
Someone had problems with some miscreant attempting (and apparently succeeding) to bruteforce a SIP account on his Asterisk system.
That's a problem. Asterisk currently has no means to protect against any type of SIP flooding/bruteforce/DoS (other than running out of resources/crashing). That's ok because some people (like myself) would argue that these types of attacks are best handled via other means...
Like the kernel, or preferably the kernel of a completely seperate box.
It got me to thinking - maybe I could whip up a script using some of the cool stuff in iptables/netfilter to mitigate these SIP DoS attacks in the kernel. I don't have a ton of time to elaborate on the script but for now here it is:
http://admin.star2star.com/sipdos
It's not great. It's not very SIP-specific. Who knows how accurate/effective/resource intensive it is. It hasn't been tested (much). For all I know, it will just make things worse. However, I think it is a step in the right direction and hopefully one of many tools that can be used to protect Asterisk and other SIP/VoIP systems.
By the way, I call it "SIP DoS Mitigation" because with any large enough DDoS attack, you are toast. ..
Speaking of other tools... We're all going to celebrate America's birthday this Friday by getting together on a conference call/IRC to talk over some of these issues with the VoIP User's Conference. Hear you there?
Monday, March 24, 2008
Q.931 Problems - Solved, sort of
It's been a long day so I'll keep this one short... Upgrading to Asterisk (libpri|zaptel) 1.4 solved my Cisco AS5350XM problem. However, now I've got a new one.
Zaptel 1.4 required a new version of Wanpipe. The new version of Wanpipe does not seem to work with mixed Ts. My T1 happens to have 12 DS0s for PRI and 12 for PPP.
I'm currently working with Sangoma to get this resolved so I can have it all!
Zaptel 1.4 required a new version of Wanpipe. The new version of Wanpipe does not seem to work with mixed Ts. My T1 happens to have 12 DS0s for PRI and 12 for PPP.
I'm currently working with Sangoma to get this resolved so I can have it all!
Friday, March 21, 2008
Why I (and presumably other people) hate telecom
Q.931.
That's it. Q-freaking-9-3-1. I suppose it's not bad considering it was developed so long ago, but really for me this protocol (and all it stands for) is why so many people (myself included) get frustrated with telecom.
I spent two hours today trying to get a call up (over PRI) from an Asterisk system to a Cisco gateway. I covered all of the basics:
Asterisk - pri_net - check
Cisco - pri_cpe - check
Asterisk - master clocking - check
T1 params - B8ZS, ESF - check
Switchtype - national/NI2 - check
D chan - 24 - check
T1 crossover cable - check
Voila! D channel up in no time (seriously, five minutes). Try to send a call - SURE, everything looks good (including caller id). The call gets setup and once there is about 1 sec of audio it gets torn down. Hmmm... Granted I am running SIP on the other side of the Cisco gateway (AS5350XM) so I start there. Let's face, if you're reading this blog you know I deal with SIP quite a bit. I'd much rather look at it than the alternative - Q.931...
Sure enough everything looks good on the SIP side. Perfect, actually. Ok fine, I guess we're going to have to go Q.931. I enable Q.931 debugging:
Asterisk:
asterisk -r
pri debug span 3
Cisco:
debug isdn q931
term mon (to log to my SSH session)
Try the call again. Same thing - one second of audio, disconnect. Here is what I get:
Cisco debug:
Mar 21 23:13:45.307: ISDN Se3/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Calling num 5043223199
Mar 21 23:13:45.311: ISDN Se3/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Called num 19412340001
Mar 21 23:13:45.311: ISDN Se3/0:23 Q931: TX -> SETUP pd = 8 callref = 0x00A3
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA18381
Preferred, Channel 1
Display i = 'Pcom2'
Calling Party Number i = 0x2180, '5043223199'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '19412340001'
Plan:ISDN, Type:National
Mar 21 23:13:45.323: ISDN Se3/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x80A3
Channel ID i = 0xA98381
Exclusive, Channel 1
Mar 21 23:13:46.371: ISDN Se3/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x80A3
Channel ID i = 0xA98381
Exclusive, Channel 1
Progress Ind i = 0x8182 - Destination address is non-ISDN
Mar 21 23:13:46.371: ISDN Se3/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x00A3
Mar 21 23:13:46.379: ISDN Se3/0:23 Q931: RX <- STATUS pd = 8 callref = 0x80A3
Cause i = 0x80E2 - Message not compatible with call state or not implemented
Call State i = 0x0A
Mar 21 23:13:46.379: ISDN Se3/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x00A3
Cause i = 0x80E408 - Invalid information element contents
Mar 21 23:13:46.403: ISDN Se3/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x80A3
Cause i = 0x8190 - Normal call clearing
Asterisk debug:
< Protocol Discriminator: Q.931 (8) len=50
< Call Ref: len= 2 (reference 164/0xA4) (Originator)
< Message type: SETUP (5)
< [04 03 80 90 a2]
< Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0)
< Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
< Ext: 1 User information layer 1: u-Law (34)
< [18 03 a1 83 81]
< Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0
< ChanSel: Reserved
< Ext: 1 Coding: 0 Number Specified Channel Type: 3
< Ext: 1 Channel: 1 ]
< [28 05 50 63 6f 6d 32]
< Display (len= 5) [ Pcom2 ]
< [6c 0c 21 80 35 30 34 33 32 32 33 31 39 39]
< Calling Number (len=14) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
< Presentation: Presentation permitted, user number not screened (0) '5043223199' ]
< [70 0c a1 31 39 34 31 32 33 34 30 30 30 31]
< Called Number (len=14) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '19412340001' ]
-- Making new call for cr 164
-- Processing Q.931 Call Setup
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 40 (cs0, Display)
-- Processing IE 108 (cs0, Calling Party Number)
-- Processing IE 112 (cs0, Called Party Number)
> Protocol Discriminator: Q.931 (8) len=10
> Call Ref: len= 2 (reference 164/0xA4) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 03 a9 83 81]
> Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
> ChanSel: Reserved
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 1 ]
-- Accepting call from '5043223199' to '19412340001' on channel 0/1, span 3
-- Executing Wait("Zap/49-1", "1") in new stack
-- Executing Answer("Zap/49-1", "") in new stack
> Protocol Discriminator: Q.931 (8) len=14
> Call Ref: len= 2 (reference 164/0xA4) (Terminator)
> Message type: CONNECT (7)
> [18 03 a9 83 81]
> Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
> ChanSel: Reserved
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 1 ]
> [1e 02 81 82]
> Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1)
> Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ]
-- Executing MusicOnHold("Zap/49-1", "") in new stack
-- Started music on hold, class 'default', on channel 'Zap/49-1'
< Protocol Discriminator: Q.931 (8) len=5
< Call Ref: len= 2 (reference 164/0xA4) (Originator)
< Message type: CONNECT ACKNOWLEDGE (15)
> Protocol Discriminator: Q.931 (8) len=12
> Call Ref: len= 2 (reference 164/0xA4) (Terminator)
> Message type: STATUS (125)
> [08 02 80 e2]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0)
> Ext: 1 Cause: Wrong message (98), class = Protocol Error (6) ]
> [14 01 0a]
> Call State (len= 3) [ Ext: 0 Coding: CCITT (ITU) standard (0) Call state: Active (10)
< Protocol Discriminator: Q.931 (8) len=10
< Call Ref: len= 2 (reference 164/0xA4) (Originator)
< Message type: RELEASE (77)
< [08 03 80 e4 08]
< Cause (len= 5) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0)
< Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (6) ]
< Cause data 1: 08 (8)
-- Processing IE 8 (cs0, Cause)
-- Channel 0/1, span 3 got hangup
-- Stopped music on hold on Zap/49-1
== Spawn extension (pri-in, 19412340001, 3) exited non-zero on 'Zap/49-1'
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request
> Protocol Discriminator: Q.931 (8) len=9
> Call Ref: len= 2 (reference 164/0xA4) (Terminator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1)
> Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
-- Hungup 'Zap/49-1'
s2s-srq-co*CLI>
Everytime I have to look at Q931 I just cringe. I MEAN CRINGE. I hate it. Look at it - all of these goofy messages, number plans, and the worst - IEs (Information Elements). Compare this to SIP (there are plenty of examples on this blog). I guess I just take it for granted. I can fire up ngrep on a network interface, turn on interpretation of carriage returns/linefeeds and go to town with something that just makes more sense. Sure to some people it probably still looks like gibberish but anyone that complains certainly hasn't seen much Q.931!
Let's look at my current problem... It appears that once the call is setup, Asterisk sends a CONNECT message, to which the Cisco quickly acknowledges with a CONNECT ACKNOWLEDGMENT (big surprise there). Here's where things get a little strange... The next message is from Asterisk (STATUS) complaining with "Message not compatible with call state or not implemented". That is pretty helpful, I'll give them that. However, what's not compatible about a standard, simple CONNECT ACK?!?!
This is wear I start to get angry. I'd like to see what's going on a little bit more. I know I have some flexibility with my IEs, for example. If I turn up the debug high enough in Asterisk I can see which IEs Asterisk identifies. I just can't see the data. From a debug standpoint, Cisco appears to give me even less. Cisco does, however, give me some pretty decent control of newer and less than standard IEs to send (and to a lesser extent, receive). That's gotta have something to do with it, I'm sure. It's even telling me "invalid information element contents". Too bad I can't actually see the IE content... Being severely limited with the tools at hand, I began to cycle through all of my IE, number plan, etc options on both sides. I even got lazy at one point and tried to set my switchtype to dms100! No dice.
Want to know the craziest part about all of this? I've done this several times before. I've brought up many a PRI to carriers, with all kinds of switchtypes, b/d channel configs, into all kinds of equipment (including Asterisk and Cisco). I've gone from Asterisk PRI -> Cisco PRI, Cisco PRI -> Cisco PRI, Asterisk PRI -> Asterisk PRI and every other combination you could imagine (although I think I covered all of them). I've never really had problems, although whenever there is a problem it means going through lines and lines of less-than-helpful Q.931 messaging to identify the problem, which gets me back to my point.
That's just the problem with telecom. It's old, slow, and inflexible. If this were a problem with SIP I could grab the packet stream with tcpdump and load it into Wireshark if I got really desperate (I'm rarely that desperate). I could watch it in real time with ngrep, complete with regex matching on payload and BPF syntax. I could try multiple SIP libraries and multiple clients. I could even tap into the WEALTH of information about SIP, including the various RFCs. Sure I know there are a lot of them but hey, at least you know where to look. I could even try different hardware very easily because hey, you don't need a $500 T1 card to play with SIP. Heck you don't even need a network. VmWare or even good ol' fashioned lo0 work just fine.
How can I do this with ISDN? Buy a T-Berd? No thanks. So here it is, Friday night, and I'm obsessing over the PRI that kicked my ass today. Anyone have any ideas?
That's it. Q-freaking-9-3-1. I suppose it's not bad considering it was developed so long ago, but really for me this protocol (and all it stands for) is why so many people (myself included) get frustrated with telecom.
I spent two hours today trying to get a call up (over PRI) from an Asterisk system to a Cisco gateway. I covered all of the basics:
Asterisk - pri_net - check
Cisco - pri_cpe - check
Asterisk - master clocking - check
T1 params - B8ZS, ESF - check
Switchtype - national/NI2 - check
D chan - 24 - check
T1 crossover cable - check
Voila! D channel up in no time (seriously, five minutes). Try to send a call - SURE, everything looks good (including caller id). The call gets setup and once there is about 1 sec of audio it gets torn down. Hmmm... Granted I am running SIP on the other side of the Cisco gateway (AS5350XM) so I start there. Let's face, if you're reading this blog you know I deal with SIP quite a bit. I'd much rather look at it than the alternative - Q.931...
Sure enough everything looks good on the SIP side. Perfect, actually. Ok fine, I guess we're going to have to go Q.931. I enable Q.931 debugging:
Asterisk:
asterisk -r
pri debug span 3
Cisco:
debug isdn q931
term mon (to log to my SSH session)
Try the call again. Same thing - one second of audio, disconnect. Here is what I get:
Cisco debug:
Mar 21 23:13:45.307: ISDN Se3/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Calling num 5043223199
Mar 21 23:13:45.311: ISDN Se3/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Called num 19412340001
Mar 21 23:13:45.311: ISDN Se3/0:23 Q931: TX -> SETUP pd = 8 callref = 0x00A3
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA18381
Preferred, Channel 1
Display i = 'Pcom2'
Calling Party Number i = 0x2180, '5043223199'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '19412340001'
Plan:ISDN, Type:National
Mar 21 23:13:45.323: ISDN Se3/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x80A3
Channel ID i = 0xA98381
Exclusive, Channel 1
Mar 21 23:13:46.371: ISDN Se3/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x80A3
Channel ID i = 0xA98381
Exclusive, Channel 1
Progress Ind i = 0x8182 - Destination address is non-ISDN
Mar 21 23:13:46.371: ISDN Se3/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x00A3
Mar 21 23:13:46.379: ISDN Se3/0:23 Q931: RX <- STATUS pd = 8 callref = 0x80A3
Cause i = 0x80E2 - Message not compatible with call state or not implemented
Call State i = 0x0A
Mar 21 23:13:46.379: ISDN Se3/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x00A3
Cause i = 0x80E408 - Invalid information element contents
Mar 21 23:13:46.403: ISDN Se3/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x80A3
Cause i = 0x8190 - Normal call clearing
Asterisk debug:
< Protocol Discriminator: Q.931 (8) len=50
< Call Ref: len= 2 (reference 164/0xA4) (Originator)
< Message type: SETUP (5)
< [04 03 80 90 a2]
< Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0)
< Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
< Ext: 1 User information layer 1: u-Law (34)
< [18 03 a1 83 81]
< Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0
< ChanSel: Reserved
< Ext: 1 Coding: 0 Number Specified Channel Type: 3
< Ext: 1 Channel: 1 ]
< [28 05 50 63 6f 6d 32]
< Display (len= 5) [ Pcom2 ]
< [6c 0c 21 80 35 30 34 33 32 32 33 31 39 39]
< Calling Number (len=14) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
< Presentation: Presentation permitted, user number not screened (0) '5043223199' ]
< [70 0c a1 31 39 34 31 32 33 34 30 30 30 31]
< Called Number (len=14) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '19412340001' ]
-- Making new call for cr 164
-- Processing Q.931 Call Setup
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 40 (cs0, Display)
-- Processing IE 108 (cs0, Calling Party Number)
-- Processing IE 112 (cs0, Called Party Number)
> Protocol Discriminator: Q.931 (8) len=10
> Call Ref: len= 2 (reference 164/0xA4) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 03 a9 83 81]
> Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
> ChanSel: Reserved
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 1 ]
-- Accepting call from '5043223199' to '19412340001' on channel 0/1, span 3
-- Executing Wait("Zap/49-1", "1") in new stack
-- Executing Answer("Zap/49-1", "") in new stack
> Protocol Discriminator: Q.931 (8) len=14
> Call Ref: len= 2 (reference 164/0xA4) (Terminator)
> Message type: CONNECT (7)
> [18 03 a9 83 81]
> Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
> ChanSel: Reserved
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 1 ]
> [1e 02 81 82]
> Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1)
> Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ]
-- Executing MusicOnHold("Zap/49-1", "") in new stack
-- Started music on hold, class 'default', on channel 'Zap/49-1'
< Protocol Discriminator: Q.931 (8) len=5
< Call Ref: len= 2 (reference 164/0xA4) (Originator)
< Message type: CONNECT ACKNOWLEDGE (15)
> Protocol Discriminator: Q.931 (8) len=12
> Call Ref: len= 2 (reference 164/0xA4) (Terminator)
> Message type: STATUS (125)
> [08 02 80 e2]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0)
> Ext: 1 Cause: Wrong message (98), class = Protocol Error (6) ]
> [14 01 0a]
> Call State (len= 3) [ Ext: 0 Coding: CCITT (ITU) standard (0) Call state: Active (10)
< Protocol Discriminator: Q.931 (8) len=10
< Call Ref: len= 2 (reference 164/0xA4) (Originator)
< Message type: RELEASE (77)
< [08 03 80 e4 08]
< Cause (len= 5) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0)
< Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (6) ]
< Cause data 1: 08 (8)
-- Processing IE 8 (cs0, Cause)
-- Channel 0/1, span 3 got hangup
-- Stopped music on hold on Zap/49-1
== Spawn extension (pri-in, 19412340001, 3) exited non-zero on 'Zap/49-1'
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request
> Protocol Discriminator: Q.931 (8) len=9
> Call Ref: len= 2 (reference 164/0xA4) (Terminator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1)
> Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
-- Hungup 'Zap/49-1'
s2s-srq-co*CLI>
Everytime I have to look at Q931 I just cringe. I MEAN CRINGE. I hate it. Look at it - all of these goofy messages, number plans, and the worst - IEs (Information Elements). Compare this to SIP (there are plenty of examples on this blog). I guess I just take it for granted. I can fire up ngrep on a network interface, turn on interpretation of carriage returns/linefeeds and go to town with something that just makes more sense. Sure to some people it probably still looks like gibberish but anyone that complains certainly hasn't seen much Q.931!
Let's look at my current problem... It appears that once the call is setup, Asterisk sends a CONNECT message, to which the Cisco quickly acknowledges with a CONNECT ACKNOWLEDGMENT (big surprise there). Here's where things get a little strange... The next message is from Asterisk (STATUS) complaining with "Message not compatible with call state or not implemented". That is pretty helpful, I'll give them that. However, what's not compatible about a standard, simple CONNECT ACK?!?!
This is wear I start to get angry. I'd like to see what's going on a little bit more. I know I have some flexibility with my IEs, for example. If I turn up the debug high enough in Asterisk I can see which IEs Asterisk identifies. I just can't see the data. From a debug standpoint, Cisco appears to give me even less. Cisco does, however, give me some pretty decent control of newer and less than standard IEs to send (and to a lesser extent, receive). That's gotta have something to do with it, I'm sure. It's even telling me "invalid information element contents". Too bad I can't actually see the IE content... Being severely limited with the tools at hand, I began to cycle through all of my IE, number plan, etc options on both sides. I even got lazy at one point and tried to set my switchtype to dms100! No dice.
Want to know the craziest part about all of this? I've done this several times before. I've brought up many a PRI to carriers, with all kinds of switchtypes, b/d channel configs, into all kinds of equipment (including Asterisk and Cisco). I've gone from Asterisk PRI -> Cisco PRI, Cisco PRI -> Cisco PRI, Asterisk PRI -> Asterisk PRI and every other combination you could imagine (although I think I covered all of them). I've never really had problems, although whenever there is a problem it means going through lines and lines of less-than-helpful Q.931 messaging to identify the problem, which gets me back to my point.
That's just the problem with telecom. It's old, slow, and inflexible. If this were a problem with SIP I could grab the packet stream with tcpdump and load it into Wireshark if I got really desperate (I'm rarely that desperate). I could watch it in real time with ngrep, complete with regex matching on payload and BPF syntax. I could try multiple SIP libraries and multiple clients. I could even tap into the WEALTH of information about SIP, including the various RFCs. Sure I know there are a lot of them but hey, at least you know where to look. I could even try different hardware very easily because hey, you don't need a $500 T1 card to play with SIP. Heck you don't even need a network. VmWare or even good ol' fashioned lo0 work just fine.
How can I do this with ISDN? Buy a T-Berd? No thanks. So here it is, Friday night, and I'm obsessing over the PRI that kicked my ass today. Anyone have any ideas?
Wednesday, March 19, 2008
More OpenSER Work
I've been working with OpenSER a lot over the last couple of weeks. I upgraded to 1.2.3, enabled TLS support, and implemented some really cool new features:
- Serial forking class
- English error messages
- Numerous code cleanups
- Much more
I'll try to find out how much of this I can share and get back to you. In the meantime I'm having a problem calling next_gw() from the LCR module. I suspect it's a db problem but I can't be sure yet...
- Serial forking class
- English error messages
- Numerous code cleanups
- Much more
I'll try to find out how much of this I can share and get back to you. In the meantime I'm having a problem calling next_gw() from the LCR module. I suspect it's a db problem but I can't be sure yet...
Subscribe to:
Posts (Atom)