This discussion is locked

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

Unanswered Question
Jun 15th, 2012

Read the bioWith 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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (6 ratings)
abouriah10 Mon, 06/18/2012 - 00:39

Dear Randy,

Could you please help me in this issue

I have Cisco E20 can not register with cisco call manager 8.6.2 and could not find the voice vlan form the switch

so could you please help

yuanwu Mon, 06/18/2012 - 03:34

Hi,  Abouriah10

Thanks for your question.  It looks like your question was not a Cisco Unified Border Element for PSTN SIP Trunks related, instead it is a E20 registration with CUCM 8.6.2 question,  please send the question to general IP Telephony community, thanks for your understanding.

Rgds/Randy

thinkdifferent Sun, 06/24/2012 - 03:24

What version of code is it running?

If its like the EX60/90's it won't pick up Voice VLAN unless you're on 5.0 code or newer

Sent from Cisco Technical Support iPad App

Ayodeji oladipo... Mon, 06/18/2012 - 01:12

Randy,

Its been documented that CUBE supports mid-call pass through. However in my production environment, this does not work as expected.

Here is the scenario..

fax-------CUCM-----------SIP Trunk-------------CUBE------SIP TRUNK--------ITSP

Region between Fax and Sip trunk=G711

CUBE Has inbound dial-peer from cucm and outbound dial-peer to ITSP using voice-class coded with G729 prefered.

With this scenario  fax transmission  failed. The call was setup using G729 but when fax negotitation started mid-call codec negotitation did not happen hence fax failed. AT the moment we are using prefix on RP for faxes and then created dial-peeron CUBE based on the matched prefix to use G711 for all outbound calls.

We had a discussion about this on this thread..

https://supportforums.cisco.com/message/3654743#3654743

Can you please advise us if fax transimission can work with voice-class codec, which will require a mid-call codec renegotiation.

Please rate useful posts

"For the love of God is broader than the measure of man's mind And the heart of the Eternal is most wonderfully kind"

yuanwu Mon, 06/18/2012 - 03:48

Hi, Aokanlawon

Thanks for your question.

Regarding to fax working over SIP with CUBE,  you need to decide which fax protocol mode you will use, either T38 or fax pass-through , both of them can be SIP protocol based, which means the ITSP has to support one of them, only with one of these 2 protocol configured from your fax machine under CUCM all the way to the ITSP through CUBE, otherwise you can only do G711 audio channel based fax where you achieved through your previous testing.

If ITSP can support either mode of T38 or fax pass-through ( not fax passthrough), the mid-call renegotiation can be done via CUBE to achieve your scenario, additional configuration will be needed.

If ITSP can support neither of them, then you can only do G711 audio channel based fax in which you can't upspeed the pre-established G729 codec to G711 which was required for fax transmission.

Rgds/Randy

Ayodeji oladipo... Mon, 06/18/2012 - 03:54

Randy,

Thanks a lot for finally clarifying this. We are using modem passthrough. The faxes are onnected using vg248 and MGCP. SO in this scenario we can only do G711 all the way?

For fax pass-through can you please help with the additional configuration or send a link to the documentation for it.

Please rate useful posts

"For the love of God is broader than the measure of man's mind And the heart of the Eternal is most wonderfully kind"

yuanwu Mon, 06/18/2012 - 04:13

Hi,  Aokanlawon

Thanks for your feedback.

Please check the following link of the different concepts for call control based pass-through, and NSE based modem passthrough.

http://www.cisco.com/en/US/partner/docs/ios/voice/fax/configuration/guide/vf_cfg_fx_passthr_ps6350_TSD_Products_Configuration_Guide_Chapter.html

There are some misunderstanding about fax pass-through, fax passthrough and modem passthrough, even at CCO since there are so many documents from time to time, some description  is not accurate.

To make a long story short, since you are using VG248, the only way you can do is , via G711u audio channel for fax,  the modem passthrough is NSE based, which is Cisco proprietary protocol, it will not be used by ITSP, the NSE packet will not be understood by the ITSP device, so you can only use G711 audio channel to make your fax work.

There will be no possibility to do Mid-call codec renegotiation for this particular setup.

Rgds/Randy

Gordon Ross Mon, 06/18/2012 - 03:45

Are there any recommned ways to configure CUBE when having multiple different PSTN providers connecting to it ? (By default, CUBE will allow anyone to talk to anyone. So it is possible that a call from PSTN provider 1 could bounce straight back out of CUBE to PSTN provider 2 without going via CUCM.)

Or is it recommended to have separate CUBEs for each PSTN provider ?

GTG

yuanwu Mon, 06/18/2012 - 03:57

Hi, Gordon

Thanks for your questions.

For your first question,  I think it depends on your dialplan design and you can send the call directly out to the second PSTN provider from your first PSTN provider using incoming dial-peer matching, outgoing dial-peer matching along with voice translation-profile.

For your second question, you can use CUBE HA feature to have 2 CUBEs as active and standby when you connect to multiple PSTN providers.

The above are just some general criteria,  the further design detail might needs some examples.

Rgds/Randy

Gordon Ross Mon, 06/18/2012 - 04:00

The outbound is the trivial part. It's the inbound I'm concerned about: How do I prevent calls from PSTN Provider 1 bouncing back out through PSTN Provider 2, without first going into CUCM ?

GTG

yuanwu Mon, 06/18/2012 - 04:18

Hi, Gordon

Thanks for your feedback.

To prevent the call from PSTN 1 to PSTN 2,  I think you can add different prefix to all the called number from PSTN1, and you can remove them via voice translation-profile while you send them to CUCM,  these modified numbers will not match the outgoing dial-peer for your PSTN2.

Rgds/Randy

jose.albino@con... Mon, 06/18/2012 - 04:11

Hello Randy,

I am doing some planning design for a Telephony provider regarding the best practices that can be aplied to several CUBE's with SIP Trunk integrations. And i would like to know your opinion regarding the impacto of MTP Software on a CUBE platform, namely on the maximum concurrent connections that a specific platform can handle.

Is there are any way that we can calculate this, as i know that the maximum sessions shown on a specific platform are normaly not considering that the same CUBE will implement MTP Software, for each concurrent connection.

Thanks in advance,

Regards,

José

yuanwu Mon, 06/18/2012 - 04:26

Hi, Jose

Thanks for your questions.

Regarding to your software MTP co-location with CUBE question,  it depends on different platforms which will have different session supported, we can provide the value to you if you can name an example platform, like Cisco3925 can support around 400 connection with software MTP.

Rgds/Randy

jose.albino@con... Mon, 06/18/2012 - 06:43

Hello Randy,

I am interested on both the 2900 and 3900 series. I was looking for a document that would explain this details but i have not yet found one that is clarifying. Is this dependent of the RAM installed on the platform as if i increase the total RAM of the Platform would i have a higher number of concurrent connections?

For example if you take the CISCO3925 with that comes with 1GB SDRAM and with a supported Maximum of 800 SIP Session ( in a specific reference and tested scenario?), if we enable Software MTP on the CUBE that will be used for each terminated call on the CUCM, we will have a support of 400 concurrent connections?

This means that in this conditions the platform would be operating with an average CPU of around 75% of its capacity?

Regards,

Jose

yuanwu Mon, 06/18/2012 - 16:47

Hi, Jose

Thanks for your feedback.

Please check the following official Q&A for your questions, 

the DRAM does affect the sessions can be supported. To support 800 sessions, 2G DRAM will be recommended.

The performance testing usually will operate at CPU below 75% usage.

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps5640/prod_qas09186a00801da69b.html

Q. What are the memory requirements for running the Cisco Unified Border Element?

A. The memory requirements for the Cisco 2800 and 3800 Series platforms  are 128 MB of flash memory and 512 MB of DRAM. For the Cisco AS5350XM  and AS5400XM platforms, 128 MB of flash memory and 1 GB of DRAM are  recommended. For the Cisco 2900 and 3900 Series platforms, 256 MB of  flash memory and 1 GB of DRAM are recommended for traffic loads of fewer  than 500 simultaneous calls. For more than 500 simultaneous calls, or  high calls-per-second (CPS) rates, 2 G of DRAM is recommended.

Q. What are the performance guidelines for the Cisco Unified Border Element?

A. The maximum number of simultaneous IP-to-IP calls that each platform  can carry depends on several parameters, including but not limited to  traffic mix, average call-hold time, call arrival rate, desired CPU  usage percentage, the codec used, transcoding, and whether or not voice  activity detection (VAD) is activated.

The  values in Table 1 assume the use of a G.711 codec, with VAD turned off,  call-hold times of 180 seconds, flow-through mode, Cisco IOS Software  Release 15.0.1M, Ethernet egress, and CPU use not to exceed 75 percent.  These values should be used as guidelines only and should not be taken  as guaranteed performance.

Table 1. Number of IP-to-IP Calls per Platform

Platform

Maximum Number of Simultaneous Calls (Flow-Through)

Cisco 3945E

2500

Cisco 3925E

2100

Cisco 3945

950

Cisco 3925

800

Cisco 2951

500

Cisco 2921

400

Cisco 2911

200

Cisco 2901

100

Cisco ASR 1004; and Cisco ASR 1006 Route Processor 2 (RP2)

5000; 15000*

Cisco ASR 1002, ASR 1004, and ASR 1006 RP1

1750

Cisco AS5350XM and AS5400XM

600

Cisco 3845

500

Cisco 3825

400

Cisco 2851

225

Cisco 2821

200

Cisco 2811

110

Cisco 2801

55

*Note: Up to 5000 calls are supported on Cisco IOS Software Release 2.5, and up to 15000 calls on Release 2.6 or later.

Rgds/Randy

jose.albino@con... Tue, 06/19/2012 - 04:34

Hello Randy,

Indeed the Q&A clarified most of my questions, and at the moment i have only one point that i would like you to clarify.

The point is regarding the impact of MTP Software co-located with the CUBE.

Can provide me some feedback on this topic?

Regards,

Jose

yuanwu Tue, 06/19/2012 - 04:56

Hi, Jose

Thanks for your feedback.

Regarding to the impact of software MTP co-located with the CUBE, there is no public data that I can give it out, sorry about that.

Please consult your local System Engineer for the platform you will deploy in your future design, basically it will support less connection compared to the information announced in the Q&A URL.

Rgds/Randy

j.huizinga Mon, 06/18/2012 - 23:56

Hello Randy,

I am implementing a CUBE device on a 3845.

I have a question avbout the MTP for SIP early offer:

Is it possible to let callmanager do a SIP delay offer (no MTP) and the CUBE do an early offer to the provider?

Would this eliminate the MTP configuration?

Jan

yuanwu Tue, 06/19/2012 - 03:22

Hi,  Jan

Thanks for your question.

Your setup is possible,  under the "voice service voip" -> "sip" configuration, there is one command "early-offer forced", once you configure this, CUBE will send the codec configured under the outgoing dial-peer pointing to the provider as the SDP information even it is delay offer call from CUCM.

This command can also be configured under the dial-peer, the command will be "voice-class sip early-offer forced", which will only take effect when  the call hits this dial-peer while the previous command under "voice service voip" will have global effect.

Rgds/Randy

marek.janecek Tue, 06/19/2012 - 01:07

Hi Randy,

we tried to set up basic SRTP-RTP topology on CUBE using this guide (CUBE Support for SRTP-RTP Internetworking) which was the only comprehensive up-to-date guide how to configure it I was able to find.

We hadn't CME license on that CUBE at the time (which is needed because transcoders have to register via SCCP), so we used "associate application cube" under dspfarm profile and it seems to work flawlessly and without that SCCP mess. Is there any problem with this solution or reason why it's not described anywhere ?

Obviously the SCCP version (with transcoders registering to CME at CUBE) have to be used if DSP resources are in other box than CUBE but is there any other drawback ?

topology:

CUCM----(Secure SIP trunk)----CUBE----(SIP trunk)----ISP

Regards

Marek

yuanwu Tue, 06/19/2012 - 03:53

Hi, Marek

Thanks for your question.

It looks like you are one of our more advanced users of CUBE, this feature was introduced recently.  You already described the advantage of this mode which will not require any CME related configuration and SCCP configuration, the SCCP controlled transcoder was replaced by Cisco internal control , and obviously without SCCP command, it can only be used locally, and it can only be supported by later IOS version with PVDM3 modules.

I can only find the following information from CCO which is for IOS-XE version of ASR1k in enterprise mode CUBE which will have the similar feature of ISR G2 as CUBE.

http://www.cisco.com/en/US/partner/docs/ios-xml/ios/voice/cube_proto/configuration/xe-3s/voi-dspbased-func.html

I will contact with the product marketing team to reflect the CCO information about this new feature, thanks.

Rgds/Randy

Ayodeji oladipo... Tue, 06/19/2012 - 03:41

Hi Randy..

I just want some clarification on ringback issues with SIP trunks. According to cisco documentation it says:

By default, Cisco Unified Communications Manager  will signal the calling phone to play local ringback if SDP is not  received in the 180 or 183 response. If SDP is included in the 180 or  183 response, instead of playing ringback locally, Cisco Unified  Communications Manager will connect media, and the calling phone will  play whatever the called device is sending (such as ringback or busy  signal).

This then suggests that If you do not receive ringback, the device to which you are  connecting may be including SDP in the 180/183 response, but it is not  sending any media before the 200OK response.

Now in cases like this, as I have one case I am troubleshooting now, I tried to use the disable early media to force cucm to play ringback locally. But it didnt work.

Also according to cisco documentation

disable-early-media 180

To specify which call treatment, early media or local ringback, is provided for 180 responses with 180

responses with Session Description Protocol (SDP), use the disable-early-media 180 command in

sip-ua configuration mode. To enable early media cut-through for 180 messages with SDP, use the no

form of this command. disable-early-media 180

config t

sip-ua

disable-early-media 180.

Can you please clarify how ringback should work over sip trunk especially in a case when the ITSP is sending 183 with SDP. If in this scenario we do not get ring back from the ITSP is there a way to force CUCM to play ringback locally.

Can the same be done for CCME too?


yuanwu Tue, 06/19/2012 - 04:13

Hi, Aokanlawon

Thanks for your questions.

1.  If ITSP sends 183 with SDP, ITSP has the responsibility to play the ringback or any audio, for the CUBE or CUCM, there is only one thing to do which is to cut through media,  by theory, the device along the way should not change it from 183 with SDP to 180 which will change the behavior and might cause further issue.

2. The command you mentioned will not help your scenario.

3. The root cause of the issue is from ITSP, it should not send 183 with SDP while not provide ringback tone.

4. If you really want to change the behavior, you can use Lua script in CUCM version later than 8.5(1)  to change the 183 message to 180, which might force the CUCM to play the local ringback. The feature in CUCM called SIP transparency and normalization.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_5_1/ccmcfg/b06scrpt.html

Rgds/Randy

Ayodeji oladipo... Tue, 06/19/2012 - 04:22

Randy as always thank you for the detailed explanation.

I guess this willbe taking back to the ITSP then. The only other thing is that when call is made towards the ITSP you can hear the called phone ringing but the cisco phone does not ring. Does this not suggest that the ITSP is playing ringback?

Secondly, then is the disable-early media 180 applicable? When can this be used?

Please rate useful posts

"For the love of God is broader than the measure of man's mind And the heart of the Eternal is most wonderfully kind"

yuanwu Tue, 06/19/2012 - 05:04

Hi, Aokanlawon

1.  in the scenario you described, the called phone ringing is different than the calling party hearing the ringback, if you saw the 183 with SDP passing through from CUBE to the CUCM and if CUCM use early offer to setup this call, and you still can't hear the ringback tone from ITSP, it will be ITSP issue, but  if the CUCM use delay offer to setup the call, it will be another story, you have to use rel1xx to cut through the ringback tone from ITSP to CUCM via CUBE.

2. the "disable-early media 180" can only affect 180 message with SDP.

Rgds/Randy

Ayodeji oladipo... Tue, 06/19/2012 - 07:36

Randy, Excellent thoughts from you. Thank you so much for clarifying this..

If this is CCME ( I know ccme does early offer by default) Can you use rel1xxx to cut through the ringback tone from ITSP?

Please rate useful posts

"For the love of God is broader than the measure of man's mind And the heart of the Eternal is most wonderfully kind"

yuanwu Tue, 06/19/2012 - 17:25

Hi, Jose

Thanks for your feedback.

If it is CCME, since it use early offer, will not have the issue while you have CUCM , the rel1xx is a compensation for CUCM delay offer.

Rgds/Randy

Gordon Ross Tue, 06/19/2012 - 06:30

Why are the debug messages for voice so hard to understand, compared to, say traditional IP debug outputs ? I *really* struggle piecing together what CUBE is doing.

GTG

yuanwu Tue, 06/19/2012 - 17:26

Hi, Gordon

Thanks for your feedback.

If you refer to "debug ccsip message", it is kind of readable, isn't it?

Rgsd/Randy

Ayodeji oladipo... Wed, 06/20/2012 - 04:33

Randy,

I want to know if its possible to make sip profiles work lke xlation rules. This is what I mean..

If I have an DN sending a divert to cube like this..

request INVITE sip-header Diversion modify ";privacy=off;reason=follow-me;screen=yes"

Can I modify the divert header such that i the DN is split like 5634*

So I can have a sip profile like this..

request INVITE sip-header Diversion modify ";privacy=off;reason=follow-me;screen=yes"

";privacy=off;reason=follow-me;screen=yes"

This is to enable me present different DDI based on the last 4 digit extension. Can this be done?

Please rate useful posts

"For the love of God is broader than the measure of man's mind And the heart of the Eternal is most wonderfully kind"

yuanwu Wed, 06/20/2012 - 05:40

Hi, Aokanlawon

Thanks for your question.

From your description,  you want to replace the user infor in the diversion header from 56345408 to 441214245408 ?

Rgds/Randy

Ayodeji oladipo... Wed, 06/20/2012 - 06:10

Yes, but I also want it to be used for 56344000, 56345000 without having to configure a new diversion header for each  number such that  56344000 is replaced with 441214245000 etc.

Can I use a single sip profile to achieve this?

Please rate useful posts

"For the love of God is broader than the measure of man's mind And the heart of the Eternal is most wonderfully kind"

yuanwu Wed, 06/20/2012 - 07:05

Hi, Aokanlawon

Please try this sip-profile,

request INVITE sip-header Diversion modify "" ""

Rgds/Randy

Ayodeji oladipo... Wed, 06/20/2012 - 07:29

Thanks Randy! This is what I was looking for

Please rate useful posts

"For the love of God is broader than the measure of man's mind And the heart of the Eternal is most wonderfully kind"

Ayodeji oladipo... Thu, 06/21/2012 - 04:44

Randy,


I have a burning question that I've needed help on for years now regarding properly binding media and signaling for SIP in CUBE.  Growing up in the Cisco world I've always been told and followed the best practice of binding media and signalling for H323, MGCP, CME and SRST to a loopback on the router and some features simply won't work unless you bind to a loopback.  This has worked great until I came across utilizing CUBE for SIP integration with CUCM and a PSTN provider such as AT&T, Verizon or Global Crossing.  What's my issue?  I can no longer bind my traffic to that loopback address and have a succesful CUBE integration with an external entity or with CUCM.  You ask how that's an issue?  When I bind to that loopback address which has an internal non public routable IP address CUBE sends out of all interfaces that Loopback interface as the source address so when my SIP traffic gets sent to the PSTN provider they have no way of getting back to that router but obviously it works for talking to CUCM.

A cisco staff responded to this by saying "I don't recommend you bind SIP on a SIPto-
SIP CUBE, since it removes the listener from the external interface. 90% of installs
shouldn't need a SIP bind on SIP to SIP since we'll source from the interfaces closest to the
destination of the SIP packet"

Can you please clarify this. In a scenario where I have an Internal IP and a public IP to talking to the provider. How should I go about binding sip signalling? It looks obvious that I cant bind to my local interface.

Secondly what does the phrase mean "we'll source from the interfaces closest to the destination of the SIP packet"  Does that suggest the Public interface?

Please rate useful posts

"For the love of God is broader than the measure of man's mind And the heart of the Eternal is most wonderfully kind"

Gordon Ross Thu, 06/21/2012 - 04:57

aokanlawon - just bind a public IP address to the loopback interface. That's what I do.

GTG

yuanwu Thu, 06/21/2012 - 05:11

Hi, Aokanlawon

Thanks for your questions.

1.  the CUBE is a natural De-Marcation point, by using address hiding, you can have internal ip address facing your internal network, and public ip address facing Provider

2. the phrase means if you don't use bind command, it will use the source address for signaling by your routing table.

Rgds/Randy

Ayodeji oladipo... Thu, 06/21/2012 - 05:31

Thanks Randy.

Yes I understand CUBE to be a demarcation point, however  in this scenario what will be the best practise? Not to use the bind command? Or where do we use the bind command?

Please rate useful posts

"For the love of God is broader than the measure of man's mind And the heart of the Eternal is most wonderfully kind"

yuanwu Thu, 06/21/2012 - 06:30

Hi, Aokanlawon

Thanks for your feedback.

1.  In general, the bind interface needs to be routable to the destination.

2. Usually we configure the bind command at dial-peer level pointing to internal or external, in which it will be quite logical for the media and signaling interface used for the traffic.

Rgds/Randy

yuanwu Thu, 06/21/2012 - 05:12

Hi, InHo Choi

Thanks for your question.

From your description, I think when you put your ip phone under BE3k on hold, then you can't resume it,right?

Usually the MOH will be played by BE3k when you put the mobile phone on hold from your ip phone while in your setup the ITSP will play the MOH.

I need to check the "debug ccsip message" from CUBE and "show running" from 881 to see what happens to the RE-INVITE messages when you resume the call.

Rgds/Randy

joyfood21 Thu, 06/21/2012 - 05:29

Hi Yuan,

I have just uploaded the files you asked.

Thanks.

joyfood21 Wed, 06/27/2012 - 18:35

Hello Randy,

I have just fixed this issue by putting "midcall-signalling block" under the VOICE SERVICE VOIP > SIP.

Could you explain if that's the right thing for my issue?

Cheers,

yuanwu Wed, 06/27/2012 - 18:57

Hi, INHO

Thanks for your update.

This command will block all the mid-call signaling,  normally it will used with another command "midcall-signaling passthru media-change" to support fax, video escalation from audio.

If you only configure this command, which is to block all mid-call signaling , then fax, video escalation calls will be failed.  You also need to verify other call flow the CUBE will have, which will be used in some specific environment.

For this ITSP environment, it can be a workaround for this issue, but it is still a bit rare for this kind of Sip implemenation.

Rgds/Randy

tenaro.gusatu.novici Thu, 06/21/2012 - 05:14

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 Thu, 06/21/2012 - 06:27

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

joyfood21 Thu, 06/21/2012 - 00:20

Hi Randy,

I hope you are very well and thanks for all your answers here. That's really helpful. Thanks again.

I am in the middle of testing BE3K with 881 CUBE router. It's working fine so far except for one thing: MOH.

Internally MOH is working fine but if I make a call to a mobile phone and put on hold then MOH is played by our ITSP.

After this happening I can't get it off hold by pressing RESUME button. My phone looks back to off hold but the mobile phone user is still listening ITSP's MOH. I have to just hang up to finish the MOH playing on the mobile phone.

Does this happen because our CUBE is not sending right information to ITSP? I am very confusing with this issue. :-)

Please help.

Thanks.

Attachment: 
yuanwu Thu, 06/21/2012 - 06:20

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

joyfood21 Thu, 06/21/2012 - 06:52

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 Thu, 06/21/2012 - 17:09

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: ;tag=4014~20e49774-f908-43f7-978f-cb8f24cd97ef-25512664

To: ;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

joyfood21 Thu, 06/21/2012 - 18:51

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? :-)

Actions

Login or Register to take actions

This Discussion

Posted June 15, 2012 at 9:39 AM
Stats:

Related Content

Discussions Leaderboard

Rank Username Points
1 21,026
2 15,047
3 10,314
4 7,999
5 4,856
Rank Username Points
159
95
75
66
55