Ask the Expert:Cisco Unified Border Element for PSTN SIP Trunks

[ciscomoderator]

With Randy Wu

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn from Cisco expert Randy Wu  best practices on how to configure and troubleshoot Cisco UBE for the public switched telephone network Session Initiation Protocol trunks.

Randy Wu is a senior customer support engineer in the Multiservice Voice team at Cisco in Sydney. He has vast experience and knowledge configuring, troubleshooting, and designing Cisco UBE, gateways, and gatekeepers, working with H323, MGCP, and SIP protocols. He joined Cisco as a systems engineer in 1999. He holds CCIE certification (#8550) in Service Provider, Routing, and Switching and Voice.

Remember to use the rating system to let Randy know if you have received an adequate response. 

Randy might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the  Collaboration, Voice and Video sub-community discussion forum shortly after the event. This event lasts through June 29, 2012. Visit this forum often to view responses to your questions and the questions of other community members.

[yuanwu]

Hi, INHO CHOI

Thanks for your upload.

I had a quick look of your debugs, it appears nothing wrong at the CUBE SIP signaling during RE-INVITE to re-establish the media after you resume,  it looks like your ip phone's ip address is 192.168.88.105, media port is udp 16488. 

when you resume your ip phone, what did you hear from your ip phone side?

It looks like the ITSP doesn't update the media information correctly when you resume your call.

Rgds/Randy

[INHO CHOI]

Hi Yuan,

When I press RESUME button on my IP Phone, I can't hear anything but the ITSP music on hold is still playing.

Being told from ITSP:

"Hello Brian,

If you have setup your PABX correctly it will be playing the music on hold that you have specified, not the one that is generated from the MNF end.

Phones that are registered directly to MNF cannot generate this tone. Every time someone places a caller on hold they send us a invite packet and then we play the hold music.

In a sip trunk/ local PABX setup when someone places the call on hold it sends a message to the PABX and the PABX will send back the hold music. If setup correctly it will not play our music.

The other problem you have described is happening because the PABX may not be setup correctly."

[yuanwu]

Hi, INHO CHOI

Thanks for your feedback.

In general, the statement from the ITSP is correct, that is why I am interested you said the mobile phone can hear the MOH from ITSP but not from BE3K, usually the mobile phone will hear the MOH from BE3k when you put your ip phone on hold.

1.  from your debug, please confirm 192.168.1.250 is your MOH server ip address with udp port 24644 when your MOH at BE3k started to stream, which lasted about 26 seconds until the call was resumed,

000731: Jun 21 05:46:42.701: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:0400208288@192.168.1.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 192.168.1.250:5060;branch=z9hG4bK7b97d9f6d19

From: <2002>;tag=4014~20e49774-f908-43f7-978f-cb8f24cd97ef-25512664

To: <0400208288>;tag=11EA3C8-14DB

Date: Thu, 21 Jun 2012 05:11:39 GMT

Call-ID: 7eafa980-fe21ace8-61e-fa01a8c0@192.168.1.250

Max-Forwards: 70

CSeq: 103 ACK

Allow-Events: presence

Content-Type: application/sdp

Content-Length: 203

v=0

o=CiscoSystemsCCM-SIP 4014 3 IN IP4 192.168.1.250

s=SIP Call

c=IN IP4 192.168.1.250

t=0 0

m=audio 24644 RTP/AVP 18

a=X-cisco-media:umoh

a=rtpmap:18 G729/8000

a=ptime:20

a=fmtp:18 annexb=no

2.  It is better to have a wireshark capture at CUBE interface facing ITSP for the call, we can decode what was played to the ITSP when it is on hold.

3.  Since the MOH music should be different between BE3K and ITSP,  if ITSP said they will not play the MOH when you put the ip phone on hold, why the mobile phone can hear the MOH from ITSP?  Please make sure you will get the same MOH music when you call any mobile phone, and put them on hold.

Rgds/Randy

[INHO CHOI]

Hi Randy,

ITSP guy is saying our device is sending invite to play their moh? That's why they are playing the MOH on the phone.

And also he is saying " do not send invite message when we press hold button to play our MOH".

I lost him... do you understand what they are saying? :-)

[yuanwu]

Hi, INHO CHOI

Thanks for your feedback.

1.  It looks like there is interoperability and different concept issue between the CUBE and ITSP.

2. If they requested like the statement you described, you need to have MTP enable from BE3k for this kind of call flow.

Rgds/Randy

[tenaro.gusatu.novici]

Hi there,

is CUBE able to support video calls too (all platforms)? Can it do transrating (squeezing incoming high BW pipe to lower values) or switching between H.261 and H.264? Does it support both SIP and H.323 video calls? Can I receive H.323 video call and configure CUBE so it converts that video to SIP protocol?

Thanks,

Tenaro

[yuanwu]

Hi, Tenaro

Thanks for your question.

1.  The CUBE is officially tested for video calls between mainly Cisco products, like CUCM, CME as call control, 9971, 8945 etc as video end points; for 3rd party integration, most of time by using "sdp pass-through" the basic video calls will work.

2.  By using PVDM3, the CUBE can do video transcoding between different codecs like H263, H264

3. For video calls via CUBE, only H323 to H323 or SIP to SIP will be supported, no support for SIP to H323 or vice versa.

Rgds/Randy

[Nizar Abuseni]

Hello Randy,

We are trying to configure SIP Trunk with Provide using CUBE, the call flow is as below:

Huawei Switch (SP) ---- SIP Trunk ----- CUBE ------ SIP Trunk ------ CUCM.

The problem is that we dont receive the invite message in our cube, i have enabled debug ccsip messages and dont see any invite when doing a test incoming call from Huawei switch. But Huawei said that they sending the invite to our cube but seems our cube dont see's it as a valid invite.

What i did is enabled sniffer capture from the same interface that cube should receive this invite and i can see the invite message in a sniffer capture, i have uploaded the sniffer capture here.

They are providing the SIP over udp transport, and the configuration of my cube is as following:

Please note that interface G0/1 is connected with Huawei SIP Trunk and the G0/0 is our internal network (CUCM).

voice service voip

address-hiding

mode border-element

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

sip

  bind control source-interface GigabitEthernet0/1

  bind media source-interface GigabitEthernet0/1

!

dial-peer voice 4003 voip

destination-pattern 9647701115199

session protocol sipv2

session target ipv4:10.200.128.120

voice-class sip bind control source-interface GigabitEthernet0/0

voice-class sip bind media source-interface GigabitEthernet0/0

dtmf-relay rtp-nte h245-alphanumeric

codec g711ulaw

no vad

!

dial-peer voice 3000 voip

session protocol sipv2

session target ipv4:192.168.155.148

incoming called-number 9647701115199

voice-class sip bind control source-interface GigabitEthernet0/1

voice-class sip bind media source-interface GigabitEthernet0/1

dtmf-relay rtp-nte h245-alphanumeric

codec g711ulaw

no vad

!

I think the issue is related with SDP, as I was reading the bellow post and seems we have same invite message, but I am not sure from that.

https://supportforums.cisco.com/thread/2094908

Best regards,

Nizar

[yuanwu]

Hi, Nizar

Thanks for your questions.

1. please provide "show tech" of the CUBE router.

2. please collect the following debugs at CUBE, "debug voip ccapi inout", "debug ccsip all" which will tell me how the CUBE treat the SIP message from the Huawei device, thanks.

Rgds/Randy

[Nizar Abuseni]

Hello Randy,

When I enable these debugs I dont see anything, this is the problem. We have captured the sniffer just before the CUBE and we can see that the invite is there, but the CUBE is not receiving it. I only see the keepalive message between CUBE and Huawei Switch.

I did the debugs you requested and also uploaded sh tech.

Thanks,

Nizar

[yuanwu]

Hi, Nizar

Thanks for your update.

From the sniffer trace, I found the SIP INVITE packet was fragmented while the OPTION message was not, the whole packet size is over 1514 bytes at ethernet frame level for INVITE.

Please try TCP protocol from HuaWei instead of UDP.

Rgds/Randy

[Nizar Abuseni]

Hello Randy,

Thank you for the infomation. Actualy they dont support  TCP, they only support UDP.

So regarding the INVITE message you mean they are not sending the INVITE as a complete message? if so what can be done from our side or what can i ask them to do? I cannot tell them to use TCP as they told me before that they dont support it.

Thanks,

Nizar

[yuanwu]

Hi, Nizar

Another follow-up suggestion for this issue, upgrade the CUBE router to 15.2.1T2. ( the exact version from CCO please).

Rgds/Randy

[Nizar Abuseni]

Hello Andy,

I did the upgrade but still dont see any invite message.

Do i have to ask them to not fragment the INVITE message in order to let the CUBE recognize it? Can we do anything else than changing the transport from UDP to TCP?

thanks,

Nizar

[yuanwu]

Hi, Nizar

Please try the following workaround,

1.  configure "no ip cef" in the router, see if it will help

2. configure " ip virtual-reassembly" on the interface which will have the incoming SIP INVITE.

Rgds/Randy