UC520 SIP Trunk DID and no voice

[calvinzhu]

Hi,

We have a UC520 as PBX. Recently we want to use external SIP service via SIP trunk.

I have set up sip-ua for registration. I can make calls from internal via SIP trunk to external numbers.

But there are two problems that are yet to be solved:

1. DID internal extension via SIP.

e.g. our sip number is 87654321. Some other numbers have been allocated to us on the same trunk: 87654322, 87654323, 87654324.

I want to achieve:

People from outside ring 87654322 will go to extension 101.

87654323 -> 102

87654324 -> 109

87654321 -> 110

voice translation-rule 100

rule 1 /87654321/ /110/

rule 2 /87654322/ /101/

rule 3 /87654323/ /102/

rule 4 /87654324/ /109/

I use voice translation rules for 'incoming called'. But we only see 87654321 as incoming called number. 86754322 only appears in SIP message 'TO:' and does not get translated to 101. So calling 87654322/3/4 all reach extension 110 instead of their intended extensions.

How can I translate DID number from 'TO:' to internal extensions?

2. When calling from internal to external through SIP, everything seems good. However when calling from external to 87654322, internal extension rings. When I pick up the phone there is no voice. Hanging up on either end will terminate the call properly.

Our UC520 is behind Cisco 887. I already set 

ip nat service sip tcp port 5060

in cisco 887, otherwise I couldn't even get SIP registered.

Could you please help?

Many thanks

[Tristan Cober]

Can you provider scrubbed invites with replacement numbers/names/IPs for us to look at? The Request header should be where destination routing is done.

The providers inbound Invite will likely be UDP. The SIP ALG for UDP and the NAT UDP timers would be something to suspect for the no audio portion.

[calvinzhu]

Thanks Tristan.

Please find attached log snip and let me know if more debug options are required. I won't be able to generate more information until Monday. But I can dig out whatever I've got.

Regards

Calvin

[calvinzhu]

Hi All,

I am glad to report that I have successfully differentiated called numbers using "incoming uri to" in dial-peer.

Step 1 translate generic incoming number(87654321) to various extensions:

voice translation-rule 3009

rule 1 /87654321/ /101/

voice translation-rule 3010

rule 1 /87654321/ /102/

voice translation-rule 3011

rule 1 /87654321/ /109/

Step 2 create voice class uri for various DID numbers:

voice class uri 200 sip

pattern 87654322@my_ip

voice class uri 201 sip

pattern 87654323@my_ip

voice class uri 202 sip

pattern 87654324@my_ip

Step 3 translation profiles:

voice translation-profile IN_87654322
translate calling 3100
translate called 3009
!
voice translation-profile IN_87654323
translate calling 3100
translate called 3010
!
voice translation-profile IN_87654324
translate calling 3100
translate called 3011

Step 4. Dial-peers

dial-peer voice 2109 voip
translation-profile incoming IN_87654322
voice-class codec 1
voice-class sip asserted-id pai
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
incoming uri to 200
dtmf-relay rtp-nte sip-notify
no vad
!
dial-peer voice 2110 voip
translation-profile incoming IN_87654323
voice-class codec 1
voice-class sip asserted-id pai
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
incoming uri to 201
dtmf-relay rtp-nte sip-notify
no vad
!
dial-peer voice 2111 voip
translation-profile incoming IN_87654324
voice-class codec 1
voice-class sip asserted-id pai
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
incoming uri to 202
dtmf-relay rtp-nte sip-notify
no vad
!

Now incoming calls can correctly reach different extensions.

Move onto the no-voice in-coming calls problem.....

Thanks

Calvin

[Ayodeji Okanlawon]

Calvin,

Thanks for posting back your solution.

Are you saying that your translation rules are now matching? I am curious because normally Cisco gateway will route request based on the request uri. We can use several sip headers like to, from, via etc to match a specific dial-peer but the called number will still be used ( in the RURI).

Out of curiosity can you please send the following

debug voip dialpeer inout

debug voice translation

debug voip ccapi inout

[calvinzhu]

Hi Ayodeji,

The matching is by uri 'TO' field:

incoming uri to 202

My particular IOS 12.4(11r)XW doesn't support voice class sip-profiles. So after matching 'TO', I translate the same incoming called number to different extensions.

Also the no voice problem is caused by codec mismatch. I still don't understand.

I had:

voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8

Then in the dial-peer I used:

voice-class codec 1

Incoming call uses codec g729(preferred codec by our SIP supplier). UC520 responded with g711. Shouldn't it match it with g729? They prefer g729 over g711ulaw.

After removing voice-class codec 1 in dial-peers, I can hear voice for incoming calls.

But the sound quality is not great, much worse than calling on the ISDN BRI port. Is there a way to force incoming party to use g711ulaw?

Now there is another issue. If I set an extension to forward all, calling that extension via DID gives me busy tone. That extension is defined as ephone-dn and used by an ephone.

Thanks

Calvin

[Ayodeji Okanlawon]

For the call forward we need to see the sip logs to know whats going on..

to please send us a "debug ccsip mess" on the UC520

Also your IOS is too old. Consider upgrading it.

For the second question, its better to ask your provider to send you G711u. There is nothing you can do in these scenario