Another quick and dirty SIP interop post.
A while back I was tasked to interface a FreeSWITCH server and a Cisco Unified Communications Manager system. Once the SIP trunk was configured on the Call Manager/CUCM side they sent an INVITE over. It didn't have an SDP.
It appeared that we needed to enable 3pcc (third party call control) in FreeSWITCH. No problem. I enabled 3pcc and interop continued.
Problems arose, however, when we needed to send the Cisco ringback. Whether it be a 180 or 183 (with or without SDP for either) this was going to be tough because with 3pcc enabled the dialog looked like so:
<-- Cisco
--> FreeSWITCH
INVITE (without SDP) <--
100 Trying -->
200 OK (with SDP) -->
ACK (with SDP) <--
So... There was no opportunity to signal progress as long as we 200 OKd the call almost immediately. Sure I probably could generate some ringback after the 200 but that would just be wrong!
As I like to say, the internet to the rescue. Not having much experience with CUCM I thought I'd ask on VoiceOps. Within a few minutes a very nice gentlemen by the name of Mark Holloway mentioned "Media Termination Point Required" as a CUCM configuration option. These were the magic words. After some research it turned out that was the configuration option I needed*. Thanks Mark!
Once "Media Termination Point Required" was enabled on the Cisco side I disabled 3pcc in FreeSWITCH and all was good. Users even get ringback now!
I also brought the issue up on the FreeSWITCH-Users mailing list and found out this has been bothering people for some time. MC from FreeSWITCH was even nice enough to start a wiki page for me to document all of this there.
Sometimes with SIP it's all about the SIMPLE achievements ;).
* That research also brought up another possibility: enabling PRACK/100rel on the CallManager side instead of "MTP Required". Of course the trouble with PRACK is there are a lot of SIP implementations (Asterisk) that don't support it. FreeSWITCH does but can crash. Many SIP implementations don't support the default CUCM configuration (INVITE w/o SDP). I was looking for the most canonical, compatible configuration possible.
Showing posts with label cisco. Show all posts
Showing posts with label cisco. Show all posts
Wednesday, May 12, 2010
Thursday, October 9, 2008
Submit Your SIP
Ever since I've started blogging and talking about SIP people have come out of the woodwork with SIP interop problems.
After giving a talk about SIP at Astricon 2008 I received several e-mails from audience members with specific SIP issues. I LOVE getting these e-mails.
Why? I love working on SIP issues. With all of the devices using SIP there is no shortage of interop problems. Just today a guy on the Asterisk mailing list had a problem with his Cisco AS5300 and Asterisk 1.2 Usually that wouldn't be a problem at all - many people (including myself) use this combination of hardware with great success.
Why was he having problems? His AS5300 was configured for GTD and Asterisk 1.2 (apparently) doesn't handle multipart SIP bodies very well. I was able to find a patch to Asterisk 1.4 to improve multipart body parsing. That was a fun one.
I got to thinking... There should be a place where people can exchange specific SIP interop tips and notes. Otherwise how are we supposed to get anything to work!?!?
I came up with such a place and it's called SubmitYourSip.com. I' ve started to fill it in a little but hopefully (with time) it will become somewhat of a SIP wiki (with a focus on interop, of course).
I'm just getting started on it but I'll be working on my MediaWiki syntax and going back through my e-mail to dig out some of these examples.
After giving a talk about SIP at Astricon 2008 I received several e-mails from audience members with specific SIP issues. I LOVE getting these e-mails.
Why? I love working on SIP issues. With all of the devices using SIP there is no shortage of interop problems. Just today a guy on the Asterisk mailing list had a problem with his Cisco AS5300 and Asterisk 1.2 Usually that wouldn't be a problem at all - many people (including myself) use this combination of hardware with great success.
Why was he having problems? His AS5300 was configured for GTD and Asterisk 1.2 (apparently) doesn't handle multipart SIP bodies very well. I was able to find a patch to Asterisk 1.4 to improve multipart body parsing. That was a fun one.
I got to thinking... There should be a place where people can exchange specific SIP interop tips and notes. Otherwise how are we supposed to get anything to work!?!?
I came up with such a place and it's called SubmitYourSip.com. I' ve started to fill it in a little but hopefully (with time) it will become somewhat of a SIP wiki (with a focus on interop, of course).
I'm just getting started on it but I'll be working on my MediaWiki syntax and going back through my e-mail to dig out some of these examples.
Thursday, July 10, 2008
Asterisk Cookbook
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.
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.
Tuesday, August 28, 2007
Monitoring BGP Feeds
Two weeks! I can't believe it has been that long since my last post. That's just crazy!
I know that I can't make it up to you but I will share something I just finished up.
BGP is cool. It is so cool to turn it up on a new router and see the entire internet's routing table with a simple command "sh ip bgp". What's cooler than that?
Feeding that table into a database, that's what!
Putting your BGP feed into a database enables all sorts of cool things. As a matter of fact, some of these are so cool I haven't even thought of them yet! For the last hour or so I've been busy working on getting this going. Here's what you will need:
- BGP feed from an upstream provider, connected to a router
- Linux machine running Quagga
- Linux machine with Perl installed (can be same machine as Quagga, mine is)
First you will need to configure your router with BGP enabled:
en
conf t
ip as-path access-list 1 deny .*
router bgp [your ASN]
neighbor [Quagga IP] remote-as 64512
neighbor [Quagga IP] transport connection-mode passive
neighbor [Quagga IP] description Quagga peer
neighbor [Quagga IP] filter-list 1 in
You will want to make sure that this machine is directly connected. If it isn't you need multihop BGP (which I won't cover right now). Here's what we're doing:
- The as-path with deny updates from your Quagga machine. We don't want some misconfiguration to actually affect your network. We just want some routes from the Cisco!
- Create the neighbor with remote-as 64512 (private ASN)
- Don't initiate a connection to this peer, let them connect to us (passive)
- Apply the filter-list to inbound traffic for this neighbor (don't allow updates from Quagga)
Now we need to configure Quagga. First, you will need to install it. Your distribution should have some packages for you. Use yum, apt, etc to grab it.
It will probably install some config files in /etc/quagga. We only want to setup bgp. This should be a good sample bgpd.conf to get you started:
hostname [your hostname]
password changeme
enable password changeme
log stdout
log syslog
service advanced-vty
!
router bgp 64512
bgp router-id [Quagga IP]
neighbor [Cisco IP] remote-as [your real ASN]
neighbor [Cisco IP] description Internet BGP Feed
neighbor 127.0.0.1 remote-as 64512
neighbor 127.0.0.1 description local db hookup
neighbor 127.0.0.1 port 9179
neighbor 127.0.0.1 passive
neighbor 127.0.0.1 filter-list 1 in
neighbor 127.0.0.1 next-hop-self
neighbor [some public ip] remote-as 64513
neighbor [some public ip] description Remote devel
neighbor [some public ip] passive
neighbor [some public ip] ebgp-multihop 255
neighbor [some public ip] filter-list 1 in
neighbor [some public ip] next-hop-self
!
access-list 1 permit [local class C network] 0.0.0.255
access-list 1 permit 127.0.0.1
access-list 1 deny any
access-list 10 permit [local class C network] 0.0.0.255
access-list 10 permit [remote ip]
access-list 10 deny any
!
ip as-path access-list 1 deny .*
!
line vty
access-class 1
After you apply this, you will want to start bgpd: "bgpd -n". It will tell you which vty you can connect to with telnet:
telnet localhost 2605
That should work. At this point, you should have a connection up to your main router:
sh ip bgp sum
BGP router identifier (deleted), local AS number 64512
29 BGP AS-PATH entries
0 BGP community entries
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
(deleted) 4 15092 580 129 0 0 0 02:06:29 9845
127.0.0.1 4 64512 167 944 0 0 0 00:58:59 0
(deleted) 4 64513 6 616 0 0 0 00:02:56 0
Total number of neighbors 3
Sweet! Hey, where did that connection from 127.0.0.1 come from? That looks strange...
That connection is the whole point of this exercise. Star2Star is interested in quality, internet routing and the relationship between the two (at least I am). Long ago we realized that having a full BGP feed and being able to analyze updates in real time could be a huge asset to our management and monitoring portfolio.
How could we do this? Within the last week it came up on NANOG. A guy named Bill Nash wrote a Perl script a while back using Net::BGP to connect to a BGP peer and dump it's routes into a MySQL database. This made much more sense than trying to pull them via SNMP or some other hackish mechanism.
Bill wrote this for another employer and no longer had access to it. Evidently enough people asked him about it off list for him to consider re-writing it. I wanted him to do more than consider... I wanted that script!
I contacted Bill and offered to support his work any way possible. This included setting up a read-only BGP feed for him. I didn't want to give him (no offense Bill) a direct connection to our Cisco router (crashing that would be BAD) so I came up with the setup above. The Quagga is read only (by configuration and with -n on the command line not even the local kernel can be updated). And the Cisco is read-only to the Quagga peer. Seems safe enough.
The Quagaa instance is merely a distributor for our BGP feed. That way I can mess with it all I want without any fear (or very little fear) of causing any problems for our main router. I can hammer it all I want with some alpha-quality perl scripts. Worst case (hopefully) I'll just hose Quagga if something goes wrong...
While waiting for Bill to get his Perl script going, I Googled BGP Perl to see if there was anything else out there. Sure enough, there is:
http://briangannon.com/2007/04/23/bgp-perl-route-analyzer/
This is a crude version of what I am looking for. I made a few minor changes because I needed it to run on the same machine as Quagga (already using TCP port 179). I also didn't want to have to run the perl script as root. Here is a mini-diff:
line 20:
-my $bgp = new Net::BGP::Process();
+my $bgp = new Net::BGP::Process( Port => 9179 );
Now when you follow the directions on Brian's blog to INSERT the BGP peer into the SQL table, make sure to just use localhost. Then the perl script will use port 9179 for itself. After all, if nothing needs to connect to it, who cares what the local port is (as long as the peer has been configured properly)? Quagga knows that peer 127.0.0.1 is on port 9179, and it works. Check this out:
6147167 | 4 | 216.134.176.0/22 | 2007-08-28 19:39:51 | 2 | Next Hop Changed,Metric Changed |
| 6147168 | 4 | 216.134.180.0/22 | 2007-08-28 19:39:51 | 2 | Next Hop Changed,Metric Changed |
| 6147169 | 4 | 216.85.83.0/24 | 2007-08-28 19:39:51 | 0 | Removal of network |
| 6147170 | 4 | 216.85.83.0/24 | 2007-08-28 19:39:57 | 1 | Added 216.85.83.0/24 |
| 6147171 | 4 | 216.85.83.0/24 | 2007-08-28 19:40:35 | 0 | Removal of network |
| 6147172 | 4 | 216.85.83.0/24 | 2007-08-28 19:41:22 | 1 | Added 216.85.83.0/24 |
| 6147173 | 4 | 207.250.244.0/23 | 2007-08-28 19:48:32 | 1 | Added 207.250.244.0/23
or the routes:
mysql> select * from route limit 9842,100;
+---------+-----------+------------------+-----------+--------+------------+---------------+
| id | router_id | prefix | next_hop | metric | local_pref | as_path |
+---------+-----------+------------------+-----------+--------+------------+---------------+
| 3045536 | 4 | 216.85.190.0/24 | 127.0.0.1 | | 100 | 15092 4323 |
| 3045638 | 4 | 198.102.2.0/24 | 127.0.0.1 | | 100 | 15092 4323 |
| 3045655 | 4 | 195.85.117.0/24 | 127.0.0.1 | | 100 | 15092 174 209 |
| 3045665 | 4 | 216.85.83.0/24 | 127.0.0.1 | 99999 | 100 | 15092 4323 |
| 3045666 | 4 | 207.250.244.0/23 | 127.0.0.1 | 99999 | 100 | 15092 4323 |
+---------+-----------+------------------+-----------+--------+------------+---------------+
That's from my MySQL db. Pretty cool, huh?
I'll be working more on this in the upcoming weeks. Bill will also be working on a much improved version of the BGP Perl script that I am working with now. I'll make sure to let everyone know how it goes!
I know that I can't make it up to you but I will share something I just finished up.
BGP is cool. It is so cool to turn it up on a new router and see the entire internet's routing table with a simple command "sh ip bgp". What's cooler than that?
Feeding that table into a database, that's what!
Putting your BGP feed into a database enables all sorts of cool things. As a matter of fact, some of these are so cool I haven't even thought of them yet! For the last hour or so I've been busy working on getting this going. Here's what you will need:
- BGP feed from an upstream provider, connected to a router
- Linux machine running Quagga
- Linux machine with Perl installed (can be same machine as Quagga, mine is)
First you will need to configure your router with BGP enabled:
en
conf t
ip as-path access-list 1 deny .*
router bgp [your ASN]
neighbor [Quagga IP] remote-as 64512
neighbor [Quagga IP] transport connection-mode passive
neighbor [Quagga IP] description Quagga peer
neighbor [Quagga IP] filter-list 1 in
You will want to make sure that this machine is directly connected. If it isn't you need multihop BGP (which I won't cover right now). Here's what we're doing:
- The as-path with deny updates from your Quagga machine. We don't want some misconfiguration to actually affect your network. We just want some routes from the Cisco!
- Create the neighbor with remote-as 64512 (private ASN)
- Don't initiate a connection to this peer, let them connect to us (passive)
- Apply the filter-list to inbound traffic for this neighbor (don't allow updates from Quagga)
Now we need to configure Quagga. First, you will need to install it. Your distribution should have some packages for you. Use yum, apt, etc to grab it.
It will probably install some config files in /etc/quagga. We only want to setup bgp. This should be a good sample bgpd.conf to get you started:
hostname [your hostname]
password changeme
enable password changeme
log stdout
log syslog
service advanced-vty
!
router bgp 64512
bgp router-id [Quagga IP]
neighbor [Cisco IP] remote-as [your real ASN]
neighbor [Cisco IP] description Internet BGP Feed
neighbor 127.0.0.1 remote-as 64512
neighbor 127.0.0.1 description local db hookup
neighbor 127.0.0.1 port 9179
neighbor 127.0.0.1 passive
neighbor 127.0.0.1 filter-list 1 in
neighbor 127.0.0.1 next-hop-self
neighbor [some public ip] remote-as 64513
neighbor [some public ip] description Remote devel
neighbor [some public ip] passive
neighbor [some public ip] ebgp-multihop 255
neighbor [some public ip] filter-list 1 in
neighbor [some public ip] next-hop-self
!
access-list 1 permit [local class C network] 0.0.0.255
access-list 1 permit 127.0.0.1
access-list 1 deny any
access-list 10 permit [local class C network] 0.0.0.255
access-list 10 permit [remote ip]
access-list 10 deny any
!
ip as-path access-list 1 deny .*
!
line vty
access-class 1
After you apply this, you will want to start bgpd: "bgpd -n". It will tell you which vty you can connect to with telnet:
telnet localhost 2605
That should work. At this point, you should have a connection up to your main router:
sh ip bgp sum
BGP router identifier (deleted), local AS number 64512
29 BGP AS-PATH entries
0 BGP community entries
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
(deleted) 4 15092 580 129 0 0 0 02:06:29 9845
127.0.0.1 4 64512 167 944 0 0 0 00:58:59 0
(deleted) 4 64513 6 616 0 0 0 00:02:56 0
Total number of neighbors 3
Sweet! Hey, where did that connection from 127.0.0.1 come from? That looks strange...
That connection is the whole point of this exercise. Star2Star is interested in quality, internet routing and the relationship between the two (at least I am). Long ago we realized that having a full BGP feed and being able to analyze updates in real time could be a huge asset to our management and monitoring portfolio.
How could we do this? Within the last week it came up on NANOG. A guy named Bill Nash wrote a Perl script a while back using Net::BGP to connect to a BGP peer and dump it's routes into a MySQL database. This made much more sense than trying to pull them via SNMP or some other hackish mechanism.
Bill wrote this for another employer and no longer had access to it. Evidently enough people asked him about it off list for him to consider re-writing it. I wanted him to do more than consider... I wanted that script!
I contacted Bill and offered to support his work any way possible. This included setting up a read-only BGP feed for him. I didn't want to give him (no offense Bill) a direct connection to our Cisco router (crashing that would be BAD) so I came up with the setup above. The Quagga is read only (by configuration and with -n on the command line not even the local kernel can be updated). And the Cisco is read-only to the Quagga peer. Seems safe enough.
The Quagaa instance is merely a distributor for our BGP feed. That way I can mess with it all I want without any fear (or very little fear) of causing any problems for our main router. I can hammer it all I want with some alpha-quality perl scripts. Worst case (hopefully) I'll just hose Quagga if something goes wrong...
While waiting for Bill to get his Perl script going, I Googled BGP Perl to see if there was anything else out there. Sure enough, there is:
http://briangannon.com/2007/04/23/bgp-perl-route-analyzer/
This is a crude version of what I am looking for. I made a few minor changes because I needed it to run on the same machine as Quagga (already using TCP port 179). I also didn't want to have to run the perl script as root. Here is a mini-diff:
line 20:
-my $bgp = new Net::BGP::Process();
+my $bgp = new Net::BGP::Process( Port => 9179 );
Now when you follow the directions on Brian's blog to INSERT the BGP peer into the SQL table, make sure to just use localhost. Then the perl script will use port 9179 for itself. After all, if nothing needs to connect to it, who cares what the local port is (as long as the peer has been configured properly)? Quagga knows that peer 127.0.0.1 is on port 9179, and it works. Check this out:
6147167 | 4 | 216.134.176.0/22 | 2007-08-28 19:39:51 | 2 | Next Hop Changed,Metric Changed |
| 6147168 | 4 | 216.134.180.0/22 | 2007-08-28 19:39:51 | 2 | Next Hop Changed,Metric Changed |
| 6147169 | 4 | 216.85.83.0/24 | 2007-08-28 19:39:51 | 0 | Removal of network |
| 6147170 | 4 | 216.85.83.0/24 | 2007-08-28 19:39:57 | 1 | Added 216.85.83.0/24 |
| 6147171 | 4 | 216.85.83.0/24 | 2007-08-28 19:40:35 | 0 | Removal of network |
| 6147172 | 4 | 216.85.83.0/24 | 2007-08-28 19:41:22 | 1 | Added 216.85.83.0/24 |
| 6147173 | 4 | 207.250.244.0/23 | 2007-08-28 19:48:32 | 1 | Added 207.250.244.0/23
or the routes:
mysql> select * from route limit 9842,100;
+---------+-----------+------------------+-----------+--------+------------+---------------+
| id | router_id | prefix | next_hop | metric | local_pref | as_path |
+---------+-----------+------------------+-----------+--------+------------+---------------+
| 3045536 | 4 | 216.85.190.0/24 | 127.0.0.1 | | 100 | 15092 4323 |
| 3045638 | 4 | 198.102.2.0/24 | 127.0.0.1 | | 100 | 15092 4323 |
| 3045655 | 4 | 195.85.117.0/24 | 127.0.0.1 | | 100 | 15092 174 209 |
| 3045665 | 4 | 216.85.83.0/24 | 127.0.0.1 | 99999 | 100 | 15092 4323 |
| 3045666 | 4 | 207.250.244.0/23 | 127.0.0.1 | 99999 | 100 | 15092 4323 |
+---------+-----------+------------------+-----------+--------+------------+---------------+
That's from my MySQL db. Pretty cool, huh?
I'll be working more on this in the upcoming weeks. Bill will also be working on a much improved version of the BGP Perl script that I am working with now. I'll make sure to let everyone know how it goes!
Tuesday, July 31, 2007
Getting Multihomed - Part 3/3
Following up to one of my first posts. We FINALLY brought up BGP with all of our providers. A call from our CEO to some people at Verizon got some things moving again. I had the circuit up with BGP the same day. Pretty amazing, huh?
Anyways, now my problem was dealing with the limited memory and tcam allocation for unicast routes. If you recall, I ordered three full BGP feeds from three different providers. With the internet pushing 226,000 routes my 3750G wasn't going to cut it:
sh platform tcam utilization
CAM Utilization for ASIC# 0 Max Used
Masks/Values Masks/values
Unicast mac addresses: 400/3200 13/44
IPv4 IGMP groups + multicast routes: 144/1152 6/26
IPv4 unicast directly-connected routes: 400/3200 13/44
IPv4 unicast indirectly-connected routes: 1040/8320 1023/8134
IPv4 policy based routing aces: 512/512 2/2
IPv4 qos aces: 512/512 8/8
IPv4 security aces: 1024/1024 23/23
Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization
So now I've got full feeds from three providers coming in. Luckily I read up on IOS route-map statements before I brought these BGP sessions up. Otherwise things could've gotten ugly. Here's what I started with:
ip as-path access-list 50 permit ^174$
ip as-path access-list 50 permit ^4323$
ip as-path access-list 50 permit ^701$
I started with just getting the ASNs we were directly connected to. And my tcam started to fill, but it wasn't close. I thought, hey, why not get some more routes while I can? I started to read up a bit more on route-maps and I figured out how to get other ASNs into my route table. I only want the networks of providers connected to my providers. Does that make sense?
Without being able to see the full table I would have no idea of what I was doing. What if I wanted Level(3)'s routes, for instance? I needed to see what was going on. Luckily an old client of mine runs FixedOrbit - the coolest site to look at BPG information. All I had to do was query my directly connected ASNs and start picking other routes I wanted. BGP would take care of the rest.
Here is a shortened version of what I ended up with:
ip as-path access-list 50 permit ^174$
ip as-path access-list 50 permit ^174_3356$
ip as-path access-list 50 permit ^174_33363$
ip as-path access-list 50 permit ^4323$
ip as-path access-list 50 permit ^4323_1668$
ip as-path access-list 50 permit ^4323_6983$
ip as-path access-list 50 permit ^4323_11456$
ip as-path access-list 50 permit ^701$
ip as-path access-list 50 permit ^701_19262$
ip as-path access-list 50 permit ^701_3356$
Now I have entries in my route table for my directly connected ASNs (174, 701, 4323) and some ASNs they are peered with - 3356, 33363, 1668, 6983, 11456, 19262. I don't have much room in my tcam but hey, that's what VXRs are for! Wow, I really want one of those (with an NPE-G2, of course) ;).
Monday, July 16, 2007
What's my name?
This is going to be a different kind of post. This post might actually be useful for people trying to solve this problem. Just the facts, ma'am.
One of the things that has repeatedly come up in my line of work is CallerID name delivery in PRI (Primary Rate Interface) ISDN (Integrated Services Digital Network) configurations. I learned more about CallerID name today than I ever wanted to know. Just kidding - I love getting into stuff like this!
PRI is great because call setup is fast and CallerID information is available instantly. Or is it? I always knew that Caller ID name is not carried over the PSTN (usually - in some countries it is). The number does (obviously), but the name is usually looked up in CNAM by the terminating switch, not the originating switch. What I didn't know is that sometimes this isn't done when the initial Q.931 Setup message comes down the PRI to signal a new call.
Sometimes this CNAM lookup takes a little while (fractions of a second) and the name is sent later in a separate Q.931 Facility message. This is true. Cisco says so (PDF). A Cisco ISDN-SIP gateway can be configured to do this one of two ways:
1) Wait until you receive the Q.931 Facility message with name and shove it into the SIP INVITE using either PAI (P-Asserted-Identity) or RPID (Remote-Party-ID). Send the INVITE to the SIP proxy (or wherever).
2) Send the INVITE ASAP, and then send a SIP INFO packet when the name shows up in the Q.931 Facility message.
The default is #2, which is screwy. Very cool, but still screwy. It is much harder to design a SIP platform that can accept the initial INVITE, begin to process the call, and then append the PAI or RPID information received in the later INFO.
Thanks to Cisco I now understand more about Q.931 and ISDN. Now I need to get this "thing" to work.
My test setup:
PRI -> Asterisk -> PRI -> AS5350XM -> SIP -> OpenSER -> SIP -> Device
I need to get Caller ID with name delivery through this whole mess, from the first PRI to the last SIP device.
The LEC provided the PRI coming into the Asterisk machine. I provided everything else. I saw several roadblocks:
1) Get the CID Name from the LEC (via PRI)
2) Pass it through Asterisk
3) Get it to the 5350 (via PRI)
4) Get it to OpenSER (via SIP)
Knowing what I now know about Caller ID with name in ISDN I knew just what to do for Asterisk. In zapata.conf, my incoming context is lec-in. Here it is (from extensions.conf):
[lec-in]
exten => NXXNXXXXXX,1,Wait(1)
exten => NXXNXXXXXX,n,DoSomethingElse
Yep, that's right. All you need is to Wait a little to get that second Facility IE. Asterisk doesn't support getting the Facility IE later and it certainly doesn't support sending a subsequent SIP INFO. That's a good thing because as I said the "other" way (SIP INFO) just seems goofy to me.
Now I needed to get the CallerID name to the 5350. It didn't seem to work. I start looking at "pri debug span 3" output to see the Q.931 goodness coming from Asterisk. I fired up "debug isdn q931" on the 5350. No dice. It looked like this bug in libpri was killing me:
http://bugs.digium.com/view.php?id=9651
This was committed to libpri SVN about a month ago. I update libpri from SVN, recompile Asterisk, and install the new chan_zap.so. I give it another shot. It looks like the 5350 is now getting the name over Q. 931. Using ngrep I look at the SIP INVITE coming into OpenSER from the 5350. I have an RPID header, but it looks strange. The name field in the Remote-Party-ID header is "pending". What the heck is that about? "pending" was not what I was seeing in Asterisk!
I opened up ngrep a bit to let my see any SIP INFO messages that might be coming later. Sure enough shortly after the SIP INVITE comes a SIP INFO message with my Caller ID name. Going back to my two configuration choices on the 5350 I knew I preferred option #1 (send everything in one SIP INVITE), even if it meant there was a little delay before the caller got audio. How could I configure the 5350 to wait a little and put it all in one SIP INVITE before the Cisco fired it off to OpenSER?
I dug around on cisco.com for a bit. Nothing - at least nothing obvious. You have to love Cisco configuration and Cisco docs. I decided to look around the internet and see if anyone else had this problem.
I looked on Google and found this:
http://puck.nether.net/pipermail/cisco-voip/2005-June/005485.html
I wondered if Mr. Adam Rothschild ever found the solution to his (my) problem. I open up another tab and write him an e-mail. Three minutes later (literally) he sends me this configuration snippet:
---Begin IOS Configuration---
interface Serial3/0:23
no ip address
load-interval 30
isdn switch-type primary-ni
isdn incoming-voice modem
isdn supp-service name calling
isdn negotiate-bchan
no isdn outgoing display-ie
no cdp enable
exit
gateway
timer receive-rtp 1200
sip-ua
disable-early-media 180
retry invite 3
retry response 3
retry bye 3
retry cancel 3
timers buffer-invite 500
---End IOS Configuration---
Let's get away from this technical mumbo-jumbo and talk about people for a minute...
Mr. Adam Rothschild got an e-mail from a random stranger across the internet referencing an obscure technical problem that he had over two years ago. In less than three minutes he dug up the solution and wrote me back. I have a SmartNet support contract on this 5350 but I doubt the techs at Cisco could have helped me any better or faster than a nice guy (Adam) helping a stranger (me).
Wipe away your tears, you sentimental fool. We're getting back to configuration. This blog is hardcore. Couldn't you tell?
I applied Adam's config to my AS5350XM running IOS 12.4(15)T. Here is the SIP INVITE from the 5350 to OpenSER:
U 192.168.0.1:61306 -> 192.168.0.10:5060
INVITE sip:9418675309@192.168.0.10:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.1:5060;x-ds0num="ISDN 3/1:D 3/1:DS1
1:DS0";branch=z9hG4bK901AB9.
Remote-Party-ID: "STAR2STAR COMM"
;party=calling;screen=no;privacy=off.
From: "STAR2STAR COMM";tag=971D8C-1203.
To:.
Date: Mon, 16 Jul 2007 21:57:24 GMT.
Call-ID: 5E99C7DC-331E11DC-8126E6C7-399CBB13@192.168.0.1.
Supported: 100rel,timer,resource-priority,replaces.
Min-SE: 1800.
Cisco-Guid: 1586976572-857608668-2150694933-1673067056.
User-Agent: Cisco-SIPGateway/IOS-12.x.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER.
CSeq: 101 INVITE.
Max-Forwards: 70.
Timestamp: 1184623044.
Contact:.
Expires: 300.
Allow-Events: telephone-event.
Content-Type: application/sdp.
Content-Disposition: session;handling=required.
Content-Length: 288.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 7275 8957 IN IP4 192.168.0.1.
s=SIP Call.
c=IN IP4 192.168.0.1.
t=0 0.
m=audio 20746 RTP/AVP 18 0 101.
c=IN IP4 192.168.0.1.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16
Yeah yeah! Look at that Caller ID name in that Remote-Party-ID header! I feel like that's the best looking SIP INVITE I have ever seen. How does one SIP INVITE look better than any other? If you don't know the answer to that question, you haven't been following along.
I wrote Adam back to let him know how it turned out. He wrote me back again, happy to hear that it worked for me. Wow, just wow.
So many things shine through in this post. In one evening I found (and patched) a bug in libpri. I learned more about Q.931 and Caller ID. I found a guy to help me put it all together. The open source development model worked. The promise of easy access to information via the internet skooled me in ISDN. Social networking proved to be very effective, even while using pre-web 2.0 technology (e-mail). Google worked (a lot).
Now I get to put it all together in this blog post to give back a little. Hopefully the next guy (or girl) trying to get some mixed up mess of SIP and ISDN devices to work together with Caller ID Name delivery will get out of the office just a little bit earlier.
One of the things that has repeatedly come up in my line of work is CallerID name delivery in PRI (Primary Rate Interface) ISDN (Integrated Services Digital Network) configurations. I learned more about CallerID name today than I ever wanted to know. Just kidding - I love getting into stuff like this!
PRI is great because call setup is fast and CallerID information is available instantly. Or is it? I always knew that Caller ID name is not carried over the PSTN (usually - in some countries it is). The number does (obviously), but the name is usually looked up in CNAM by the terminating switch, not the originating switch. What I didn't know is that sometimes this isn't done when the initial Q.931 Setup message comes down the PRI to signal a new call.
Sometimes this CNAM lookup takes a little while (fractions of a second) and the name is sent later in a separate Q.931 Facility message. This is true. Cisco says so (PDF). A Cisco ISDN-SIP gateway can be configured to do this one of two ways:
1) Wait until you receive the Q.931 Facility message with name and shove it into the SIP INVITE using either PAI (P-Asserted-Identity) or RPID (Remote-Party-ID). Send the INVITE to the SIP proxy (or wherever).
2) Send the INVITE ASAP, and then send a SIP INFO packet when the name shows up in the Q.931 Facility message.
The default is #2, which is screwy. Very cool, but still screwy. It is much harder to design a SIP platform that can accept the initial INVITE, begin to process the call, and then append the PAI or RPID information received in the later INFO.
Thanks to Cisco I now understand more about Q.931 and ISDN. Now I need to get this "thing" to work.
My test setup:
PRI -> Asterisk -> PRI -> AS5350XM -> SIP -> OpenSER -> SIP -> Device
I need to get Caller ID with name delivery through this whole mess, from the first PRI to the last SIP device.
The LEC provided the PRI coming into the Asterisk machine. I provided everything else. I saw several roadblocks:
1) Get the CID Name from the LEC (via PRI)
2) Pass it through Asterisk
3) Get it to the 5350 (via PRI)
4) Get it to OpenSER (via SIP)
Knowing what I now know about Caller ID with name in ISDN I knew just what to do for Asterisk. In zapata.conf, my incoming context is lec-in. Here it is (from extensions.conf):
[lec-in]
exten => NXXNXXXXXX,1,Wait(1)
exten => NXXNXXXXXX,n,DoSomethingElse
Yep, that's right. All you need is to Wait a little to get that second Facility IE. Asterisk doesn't support getting the Facility IE later and it certainly doesn't support sending a subsequent SIP INFO. That's a good thing because as I said the "other" way (SIP INFO) just seems goofy to me.
Now I needed to get the CallerID name to the 5350. It didn't seem to work. I start looking at "pri debug span 3" output to see the Q.931 goodness coming from Asterisk. I fired up "debug isdn q931" on the 5350. No dice. It looked like this bug in libpri was killing me:
http://bugs.digium.com/view.php?id=9651
This was committed to libpri SVN about a month ago. I update libpri from SVN, recompile Asterisk, and install the new chan_zap.so. I give it another shot. It looks like the 5350 is now getting the name over Q. 931. Using ngrep I look at the SIP INVITE coming into OpenSER from the 5350. I have an RPID header, but it looks strange. The name field in the Remote-Party-ID header is "pending". What the heck is that about? "pending" was not what I was seeing in Asterisk!
I opened up ngrep a bit to let my see any SIP INFO messages that might be coming later. Sure enough shortly after the SIP INVITE comes a SIP INFO message with my Caller ID name. Going back to my two configuration choices on the 5350 I knew I preferred option #1 (send everything in one SIP INVITE), even if it meant there was a little delay before the caller got audio. How could I configure the 5350 to wait a little and put it all in one SIP INVITE before the Cisco fired it off to OpenSER?
I dug around on cisco.com for a bit. Nothing - at least nothing obvious. You have to love Cisco configuration and Cisco docs. I decided to look around the internet and see if anyone else had this problem.
I looked on Google and found this:
http://puck.nether.net/piperma
I wondered if Mr. Adam Rothschild ever found the solution to his (my) problem. I open up another tab and write him an e-mail. Three minutes later (literally) he sends me this configuration snippet:
---Begin IOS Configuration---
interface Serial3/0:23
no ip address
load-interval 30
isdn switch-type primary-ni
isdn incoming-voice modem
isdn supp-service name calling
isdn negotiate-bchan
no isdn outgoing display-ie
no cdp enable
exit
gateway
timer receive-rtp 1200
sip-ua
disable-early-media 180
retry invite 3
retry response 3
retry bye 3
retry cancel 3
timers buffer-invite 500
---End IOS Configuration---
Let's get away from this technical mumbo-jumbo and talk about people for a minute...
Mr. Adam Rothschild got an e-mail from a random stranger across the internet referencing an obscure technical problem that he had over two years ago. In less than three minutes he dug up the solution and wrote me back. I have a SmartNet support contract on this 5350 but I doubt the techs at Cisco could have helped me any better or faster than a nice guy (Adam) helping a stranger (me).
Wipe away your tears, you sentimental fool. We're getting back to configuration. This blog is hardcore. Couldn't you tell?
I applied Adam's config to my AS5350XM running IOS 12.4(15)T. Here is the SIP INVITE from the 5350 to OpenSER:
U 192.168.0.1:61306 -> 192.168.0.10:5060
INVITE sip:9418675309@192.168.0.10:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.1:5060;x-ds0num="ISDN 3/1:D 3/1:DS1
1:DS0";branch=z9hG4bK901AB9.
Remote-Party-ID: "STAR2STAR COMM"
From: "STAR2STAR COMM"
To:
Date: Mon, 16 Jul 2007 21:57:24 GMT.
Call-ID: 5E99C7DC-331E11DC-8126E6C7-399CBB13@192.168.0.1.
Supported: 100rel,timer,resource-priority,replaces.
Min-SE: 1800.
Cisco-Guid: 1586976572-857608668-2150694933-1673067056.
User-Agent: Cisco-SIPGateway/IOS-12.x.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER.
CSeq: 101 INVITE.
Max-Forwards: 70.
Timestamp: 1184623044.
Contact:
Expires: 300.
Allow-Events: telephone-event.
Content-Type: application/sdp.
Content-Disposition: session;handling=required.
Content-Length: 288.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 7275 8957 IN IP4 192.168.0.1.
s=SIP Call.
c=IN IP4 192.168.0.1.
t=0 0.
m=audio 20746 RTP/AVP 18 0 101.
c=IN IP4 192.168.0.1.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16
Yeah yeah! Look at that Caller ID name in that Remote-Party-ID header! I feel like that's the best looking SIP INVITE I have ever seen. How does one SIP INVITE look better than any other? If you don't know the answer to that question, you haven't been following along.
I wrote Adam back to let him know how it turned out. He wrote me back again, happy to hear that it worked for me. Wow, just wow.
So many things shine through in this post. In one evening I found (and patched) a bug in libpri. I learned more about Q.931 and Caller ID. I found a guy to help me put it all together. The open source development model worked. The promise of easy access to information via the internet skooled me in ISDN. Social networking proved to be very effective, even while using pre-web 2.0 technology (e-mail). Google worked (a lot).
Now I get to put it all together in this blog post to give back a little. Hopefully the next guy (or girl) trying to get some mixed up mess of SIP and ISDN devices to work together with Caller ID Name delivery will get out of the office just a little bit earlier.
Friday, July 13, 2007
Getting Multihomed - Parts 1,2
WARNING: This is going to be a long post. You probably won't make it to the end. I guess that's what happens when I go this long without having a blog.
Since moving into our colo in Tampa way back when, Star2Star has been getting blended bandwidth from our colo facility (E-Solutions). First they had three providers (Verizon/MCI/UUnet, Global Crossing, Level3). Then two (Global Crossing, Level3).
Starting in February, Global Crossing started having some big problems. Mostly packet loss in a router in Miami. Not only did it happen frequently, it was bad (%50 - %60 loss). You can imagine what that does for VoIP...
We are obsessed with quality, so about four months ago we decided to get multihomed. Seems easy enough, right? Get the right equipment, order some circuits, do the BGP thing.
Let's start with the good equipment. We have been using the awesome Cisco Catalyst 3750 to form our redundant switch stack (two 3750G-24-TS-1U configured with STP to the colo's 4500). My buddy Anton Kapela at Five9s Data suggested them. How I love these switches:
- Good stacking (Cisco StackWise)
- Good performance (65.7mpps - that's over 65 million packets per second across the backplane)
- Good performance, with features. That's right, you can do QoS, ACLs, etc at wire speed, per port (within the limits of the TCAM, obviously).
- 24 +4 port density in 1U (24 GigE copper + four GBIC slots)
- More router-type functionality (with EMI software image - gives BGP, etc)
So with a little configuration I should be able to use one of these (right now I just grabbed a spare) to form our BGP capable router to aggregate all of these circuits. Remember those great services I talked about before? Remember the tcam? Turns out that it can only handle about 8,000 unicast routes before it starts to drop into software forwarding/otherwise start to act up. Not that big of a surprise, with the current full BGP table on the internet pushing 225K+ routes the 128MB of RAM in the 3750 wouldn't have done much good anyways. With our configuration (providers directly connected, aggregated routes only) 8000 unicast routes should be just fine. Sure we lose some end to end visibility, but it's still better than what we've got now.
It might not be the perfect equipment (it's no VXR, that's for sure) but it should get us started. Now I have to order some circuits...
We take a look at the customers we have now, the providers they have, the big providers in the area, all of that good stuff. We determine we would like to get (in no order):
- Cogent
- Verizon
- Time Warner
Cogent! Yes, I know, Cogent. Cogent sticks out on that list. Let's start with them.
Dealing with the sales guy was great. Very responsive. The price (I'm sure you know) was tough to beat. Even better than price, there was another perk...
Remember that huge global internet routing table I was talking about? There are many advertised networks in it, all with varying sizes. Some are a full Class A (/8), some are less than a Class C (/24). Or are they? It turns out that most providers/network admins/BGP snobs filter any announcement smaller than a full Class C (/24). Make sense. That table is out of control! Router memory is expensive! There is old equipment! What are those less-than-a-full-class-C small fries doing messing with BGP anyways?
What is someone with a currently small network supposed to do if they want to multihome? We need BGP to control our own routing and peer with other networks and providers. We don't have enough machines to justify the current ARIN/ISP policy of %25/%50 utilization for IP addresses to get a full class C.
It turns out that ARIN has been thinking of us. That's why there is ARIN policy 2001-2. This policy, in short, says that if you can prove you are multihoming, your ISP can give you a full Class C no questions asked. Out of the three providers mentioned above Cogent was the only provider that had even heard of this and they were more than happy to do the allocation. Thanks Cogent! (Why does everyone hate them so much?)
Don't get me wrong. I am really interested in IPv6. I know global IPv4 address space is shrinking. Hacks like NAT are running out too and it is only a matter of time before we run out of IP address space and the internet comes to a halt. Whatever. At the rate Star2Star is growing we'll need all of those IPs soon enough. When the internet really needs IPv6 all of the really smart internet god types will figure it out. I'm not worried.
So we have one provider. We have a class C. Now we need to get an ASN. Before we do that, we need to make the various contacts that ARIN requires. I started with applications for the OrgID and NocID (I think - can't remember exactly now). Much to my surprise, the turnaround time on both of these was less than one hour even though I didn't start until about 5:30 PM on a Friday. I guess they don't believe in P.O.E.T.S Day over at ARIN!
We get approved for the ASN in a day or so. Fax in the contract. Give them their $500. Now we need to wait until the good 'ol US Postal Service delivers TWO copies of our signed contract. I guess ARIN really wants to hold us to that one. Don't worry ARIN I promise we'll keep up our end of the deal. You've been great so far. Two days later (USPS Florida -> Virginia) our ASN (15092) is approved and will be in WHOIS the next day. Fantastic!
We order two more circuits. One from Time Warner, one from Verizon/MCI. Time Warner installs the circuit fairly easily. They give us a /30 and everything is good. Now we just need BGP.
So far I have filled out the Time Warner BGP request form three times. No response, not even an automated one. I have e-mailed tech support. No response, not even an automated one. I have called tech support. They say they can't do anything until I fill out the form. They say they have no requests from me. What gives?!?!? I'm giving up on them for now. At least until next week Monday. I don't give up easily.
Next we deal with Verizon. This has been interesting. Most people know of at least three Verizon-type companies:
- Verizon Wireless (cell phones)
- Verizon local (the ILEC)
- Verizon Business (used to be MCI, I guess)
So far, I have heard the following business names while trying to order/turn up this circuit:
- Verizon
- Verizon Legacy
- Verizon Core
- Verizon Business
- MCI
- UUNET
That's right: UUNET. Are you kidding me? Having six different names for your company is confusing enough. Using UUNET certainly doesn't help. Last time I heard UUNET it was the nineties and I was in middle school. I had to look it up on Wikipedia just to make sure she wasn't totally confused. Turns out it goes something like this:
UUNET -> MCI -> Verizon Business
So far their name hasn't been the only thing they are confused about. I don't even want to get into it right now. I'll make sure to update everyone as the Verizon/MCI/UUNET saga continues.
What is most surprising about all of this? Cogent. With it's horrible reputation and low cost half the people I talk to still cringe at the mention of the "C word". I can tell you this: they have been (by far) the easiest to deal with. Amazing. We'll see how the service is but as of now I am a happy Cogent customer. Anyone that would like to argue about them can try to deal with some of these other characters. Let me know how it goes!
Since moving into our colo in Tampa way back when, Star2Star has been getting blended bandwidth from our colo facility (E-Solutions). First they had three providers (Verizon/MCI/UUnet, Global Crossing, Level3). Then two (Global Crossing, Level3).
Starting in February, Global Crossing started having some big problems. Mostly packet loss in a router in Miami. Not only did it happen frequently, it was bad (%50 - %60 loss). You can imagine what that does for VoIP...
We are obsessed with quality, so about four months ago we decided to get multihomed. Seems easy enough, right? Get the right equipment, order some circuits, do the BGP thing.
Let's start with the good equipment. We have been using the awesome Cisco Catalyst 3750 to form our redundant switch stack (two 3750G-24-TS-1U configured with STP to the colo's 4500). My buddy Anton Kapela at Five9s Data suggested them. How I love these switches:
- Good stacking (Cisco StackWise)
- Good performance (65.7mpps - that's over 65 million packets per second across the backplane)
- Good performance, with features. That's right, you can do QoS, ACLs, etc at wire speed, per port (within the limits of the TCAM, obviously).
- 24 +4 port density in 1U (24 GigE copper + four GBIC slots)
- More router-type functionality (with EMI software image - gives BGP, etc)
So with a little configuration I should be able to use one of these (right now I just grabbed a spare) to form our BGP capable router to aggregate all of these circuits. Remember those great services I talked about before? Remember the tcam? Turns out that it can only handle about 8,000 unicast routes before it starts to drop into software forwarding/otherwise start to act up. Not that big of a surprise, with the current full BGP table on the internet pushing 225K+ routes the 128MB of RAM in the 3750 wouldn't have done much good anyways. With our configuration (providers directly connected, aggregated routes only) 8000 unicast routes should be just fine. Sure we lose some end to end visibility, but it's still better than what we've got now.
It might not be the perfect equipment (it's no VXR, that's for sure) but it should get us started. Now I have to order some circuits...
We take a look at the customers we have now, the providers they have, the big providers in the area, all of that good stuff. We determine we would like to get (in no order):
- Cogent
- Verizon
- Time Warner
Cogent! Yes, I know, Cogent. Cogent sticks out on that list. Let's start with them.
Dealing with the sales guy was great. Very responsive. The price (I'm sure you know) was tough to beat. Even better than price, there was another perk...
Remember that huge global internet routing table I was talking about? There are many advertised networks in it, all with varying sizes. Some are a full Class A (/8), some are less than a Class C (/24). Or are they? It turns out that most providers/network admins/BGP snobs filter any announcement smaller than a full Class C (/24). Make sense. That table is out of control! Router memory is expensive! There is old equipment! What are those less-than-a-full-class-C small fries doing messing with BGP anyways?
What is someone with a currently small network supposed to do if they want to multihome? We need BGP to control our own routing and peer with other networks and providers. We don't have enough machines to justify the current ARIN/ISP policy of %25/%50 utilization for IP addresses to get a full class C.
It turns out that ARIN has been thinking of us. That's why there is ARIN policy 2001-2. This policy, in short, says that if you can prove you are multihoming, your ISP can give you a full Class C no questions asked. Out of the three providers mentioned above Cogent was the only provider that had even heard of this and they were more than happy to do the allocation. Thanks Cogent! (Why does everyone hate them so much?)
Don't get me wrong. I am really interested in IPv6. I know global IPv4 address space is shrinking. Hacks like NAT are running out too and it is only a matter of time before we run out of IP address space and the internet comes to a halt. Whatever. At the rate Star2Star is growing we'll need all of those IPs soon enough. When the internet really needs IPv6 all of the really smart internet god types will figure it out. I'm not worried.
So we have one provider. We have a class C. Now we need to get an ASN. Before we do that, we need to make the various contacts that ARIN requires. I started with applications for the OrgID and NocID (I think - can't remember exactly now). Much to my surprise, the turnaround time on both of these was less than one hour even though I didn't start until about 5:30 PM on a Friday. I guess they don't believe in P.O.E.T.S Day over at ARIN!
We get approved for the ASN in a day or so. Fax in the contract. Give them their $500. Now we need to wait until the good 'ol US Postal Service delivers TWO copies of our signed contract. I guess ARIN really wants to hold us to that one. Don't worry ARIN I promise we'll keep up our end of the deal. You've been great so far. Two days later (USPS Florida -> Virginia) our ASN (15092) is approved and will be in WHOIS the next day. Fantastic!
We order two more circuits. One from Time Warner, one from Verizon/MCI. Time Warner installs the circuit fairly easily. They give us a /30 and everything is good. Now we just need BGP.
So far I have filled out the Time Warner BGP request form three times. No response, not even an automated one. I have e-mailed tech support. No response, not even an automated one. I have called tech support. They say they can't do anything until I fill out the form. They say they have no requests from me. What gives?!?!? I'm giving up on them for now. At least until next week Monday. I don't give up easily.
Next we deal with Verizon. This has been interesting. Most people know of at least three Verizon-type companies:
- Verizon Wireless (cell phones)
- Verizon local (the ILEC)
- Verizon Business (used to be MCI, I guess)
So far, I have heard the following business names while trying to order/turn up this circuit:
- Verizon
- Verizon Legacy
- Verizon Core
- Verizon Business
- MCI
- UUNET
That's right: UUNET. Are you kidding me? Having six different names for your company is confusing enough. Using UUNET certainly doesn't help. Last time I heard UUNET it was the nineties and I was in middle school. I had to look it up on Wikipedia just to make sure she wasn't totally confused. Turns out it goes something like this:
UUNET -> MCI -> Verizon Business
So far their name hasn't been the only thing they are confused about. I don't even want to get into it right now. I'll make sure to update everyone as the Verizon/MCI/UUNET saga continues.
What is most surprising about all of this? Cogent. With it's horrible reputation and low cost half the people I talk to still cringe at the mention of the "C word". I can tell you this: they have been (by far) the easiest to deal with. Amazing. We'll see how the service is but as of now I am a happy Cogent customer. Anyone that would like to argue about them can try to deal with some of these other characters. Let me know how it goes!
Subscribe to:
Posts (Atom)