SIP Normalization

Hi ,

Recently , I had to configure a SIP trunk to operate with Microsoft Exchange as voicemail system but as the integrator of the exchange doesn’t know a lot about his system , he was unable to configure the voicemail boxes with the correct number so it gave me some mistake as Exhange was unable to resolve the  called number . So after some searches , I found that we can use the SIP Normalization as in the CUBE but this time directly in the CUCM .

The SIP normalization for SIP trunk on CUCM is based on lua ( an old application language) but even if you have no complex structure , you can easily modify the SIP stack in the inbound and outbound direction.

So you need to read the cisco documentation to master but after an half day you can already play with it to have something.

Lua is really something that you need to try when you need to update a little your sip fields/option and which is really powerful . I will come on later on this post to put a short example.

🙂

 

ATA 187 Discovery

Hi ,

It can seem dumb , but I’ve just played/discovered the ATA 187 ( which is working in SIP) . while I was trying to enter in the IVR menu , I was prompted for a password that we have not in the past.So after one or two google line , I finally discovered that the default password is cisco ( yeah I know , they are very hard 🙂 ) , so in numeric it is giving you 24726.

numb advise of the day 🙂 lol

 

CUVA 2.2 with 7941

Hey Oliver,

I came across your blog when doing some research and its totally great. I have been struggling with getting CUVA to work with our deskphones.

To give you a quick background, we are running UCCE version 7.5. Our Desk phones are 7941’s with the latest firmware (9-1-1SR1S). All deskphones are configured as SIP.

Im running Video Advantage verion 2.2 (which supports SIP video) and cannot get the phone to integrate with the video software.  CUVA works perfectly fine with a deskphone. One theory I had was the windows firewall was blocking CUVA from speaking with the 7941 but after disabling it, Im still experiencing the issue.

Is there soemthing major that Im missing, which is causing the webcam to no communicate with the phone?

Thanks,

Jim

 

CUE Basic Integration with CME

Here are all the steps to perform if you want to integrate the CUE with the CME

  1. Create a SIP dial peer pointing to the CUE Module
  2. Configure the MWI On/Off extensions
  3. Configure the connectivity between CME and CUE Modules
  4. Perform CUE Configuration

For the first step , your dial peer will look like

dial-peer voice 1000 voip
destination-pattern 5555
session protocol sipv2
session target ipv4:172.17.1.1
dtmf-relay sip-notify
codec g711ulaw
no vad
!

The configurations of the MWI On/Off must be generic as it must cover all numbers and it is generally implemented as a kind of prefix as the MWI must know which number must be turned on or off. So it adds the number after the extension the MWI shortcut.

ephone-dn 50
number 5000….
mwi on
!
ephone-dn 60
number 6000….
mwi off

Regarding the link configuration between the CUE and CME, you need to borrow the Ethernet interface where the CUE module resides (don’t forget that CME and CUE can be splitted). So everything under the service-engine ( this is the CUE module) will rely on the Ethernet interfaces:

interface Service-Engine 1/0
ip unnumbered FastEthernet 1/0
service-module ip address 172.17.1.1 255.255.255.0
service-module ip default-gateway 172.17.1.254
!
ip route 172.17.1.1 255.255.255.255 Service-Engine1/0
!

In a multi-site implementations , you have then to configure a translation between your remote CME and the central CUE/CME because we told before that CUE relies on SIP Protocol and the rest of your network is an H323 network , so you need to translate all H323 request to SIP. You can do it generally with the config:

!
voice service voip
allow-connections H323 to sip

SIP Forward to Unity

When a SIP Proxy Server forwards calls to Unity, it includes the following information:

  • The called party extension included in the Diversion Header
  • The reason why the call was forwarded in the Diversion Header
  • The extension of the calling party (internal calls) or SIP URL of the calling party in the FROM header.
Page 1 of 212