Gateway Configs

I having been getting pressure to blog something, so here it is. I received an email from a project manager for some technical help on one of his current projects. I had a project over a year ago where I installed some 7925 wireless phones and integrated with a nurse call system.

When I first read the email, it was like he was speaking a foreign language. The nurse call vendor was asking the engineer on the project for a dial back string. They were asking me if I knew what that was. I was like no, who can remember that shit? So I went to sleep that night and said to myself, “self look at my emails and notes and see if you can’t un-fuck his shit.”

In the morning with a little clearer mind, I started digging through my notes and email. I found something in the first few emails. I started to write up a response but then I realized it was the wrong answer. I finally remembered what I had to do to get it to work. The engineer had configured the FXS ports as MGCP since that was what the sow stated. I said woa, un-fuck that shit, it has to be H.323 since you need dial-peers to insert a pause in the dial string coming from the wireless phone.

You see the nurse call system was interfaced through FXS ports which then went out to the speaker on the hospital bed. The FXS ports were just the method of connecting over to the nurse call system. Once the call rang on the FXS port the nurse call system would answer the call and expect DTMF tones to tell it the room or bed number. So from the wireless phone the nurse would press a button after receiving a text message as an alert from the bed. That would trigger a phone call from the wireless phone to a number string, 1995000303#, for example. In CUCM I created a route pattern of 1995000!# and routed it to the H.323 gateway, stripping the “#”. The gateway then had a dial-peer which would strip 1995000 and “prefix ,,”. See below for example.

!
dial-peer voice 1995000 pots
preference 1
destination-pattern 1995000.T
progress_ind setup enable 3
incoming called-number .
port 0/1/0
prefix ,,
!

So after explaining how digits are stripped by default from destination-patterns unless a no digit strip command is used, I told him to un-fuck his config and make everything h.323 so that he can insert a pause in the middle of a dial string to only forward the room or bed number to the nurse call system.

Sometimes it is good to dust off the old neurons and have to remember shit you don’t use everyday.

We recently deployed a shit ton of Cisco 7841 phones.  We ran 95% of the ATP successfully and then got to the best part.  We get to knock down the WAN and send the phones into SRST mode.  For the first 10 minutes everything looked peachy, then all of a sudden the SIP registrations on the gateway decided to be punk ass bitches.  We were holding steady at around 200 registrations when we had close to 600 SIP endpoints.  Three of us stared at Secure CRT with the same anticipation as a 6 year old on Christmas morning.  Unfortunately we suffered the same disappointment as most kids who ask for a bike for Christmas and then received a box full of beaver droppings.  The registrations stopped and then at one point started losing registrations.  This was some bull shit.  It was late and we wanted to go drinking.  Well of course after an hour of troubleshooting this stupid shit, I made the brilliant assessment that I should probably call the “experts” at Cisco TAC.  So after 5 hours on the call with backbone support and then getting developers involved, we came to the conclusion that the firmware load we are using has issues with SRST.

SO FYI this load “sip78xx.10-1-1SR2-1” can lick my sack.

We added this beauty “sip78xx.10-1-1ES7” and guess what….those little bitches registered.  However, we didn’t want to introduce a new load cluster wide without doing a major bug scrub.  So we rolled back and decided that if the system goes into SRST mode…some of those people are just fucked.

I’ve got a secret stash of sample configs for voice gateways. It’s a great thing to have, especially when they are configs you’ve developed over the years and know inside and out. Sometimes, though, I end up applying a template that came from another environment or another engineer without scrutinizing every last detail.

This is what happened on a recent deployment – we got a report that when calling out to a conferencing service, DTMF was not working, and people couldn’t enter their userID / PIN.

Our incoming voip call leg was matching a dial peer something like this:

dial-peer voice 2 voip
session protocol sipv2
incoming called-number .
voice-class codec 1
dtmf-relay h245-alphanumeric
no vad

Did you notice anything strange about the bolded items? We specified sipv2 as the session protocol, but h245 for the dtmf relay method. Can you say whiskey tango foxtrot?

h245-alphanumeric only works on an H.323 gateway / dial-peer / trunk, but that shit is old-school and we’re all SIP here.

It IS important that you pay attention to the DTMF signaling method on the SIP trunk in this scenario. We had the default of ‘No Preference’:

Screen Shot 2015-03-23 at 11.56.35 AM

‘No Preference’ is typically the ideal setting – it tries to negotiate the method automagically and keep the use of MTP’s to a minimum. You can read more about these settings the SRND

So, long story short, we had to unfuck our shit, and set the dtmf-relay to rtp-nte like the example below. Once we did this, all was good in the hood once again.

dial-peer voice 2 voip
session protocol sipv2
incoming called-number .
voice-class codec 1
dtmf-relay rtp-nre
no vad

 

 

So – something that I should have known already, but just learned today is how dial-peers are matched when you have multiple matches with the same preference.

It seems kinda fucked up to me, but this is how it works – the router matches the first one in the config from top to bottom, and the tag doesn’t matter one bit.

Also, when you remove a dial-peer and add it back in, they go in at the bottom, so you end up with stuff like this:

dial-peer voice 3240 voip
description BTN
destination-pattern 14044166969
session protocol sipv2
session target ipv4:10.110.61.209
incoming called-number .
voice-class codec 1
dtmf-relay rtp-nte
no vad

 

dial-peer voice 100 voip
description L1 911 Call Back
destination-pattern 14044166970
session protocol sipv2
session target ipv4:10.110.61.209
incoming called-number .
voice-class codec 1
dtmf-relay rtp-nte
no vad

 

dial-peer voice 200 voip
description L2 911 Call Back
destination-pattern 14044166970
session protocol sipv2
session target ipv4:10.98.61.221
incoming called-number .
voice-class codec 1
dtmf-relay rtp-nte
no vad

 

So – which dial-peer does an incoming VOIP call match? 3240, of course!

Really – it would be better to remove that “incoming called-number .” from all but one dial-peer, but this is the leftover junk that shows up from time to time.