CUBE, MoH issue with flow-around mode

[cjrchoi11]

Hi,

CUCM--CUBE--SBC(carrier)

-SIP to SIP

-no MTP in CUCM SIP Trunk interface

-CUCM=5.1.3

-CUBE=12.4.22.T1

MoH not works when CUBE configure 'flow-around' mode. when IP Phone press Hold button, CUCM kicks MoH but PSTN phone loose the RTP stream. it works okay with 'flow-through' mode.

Advise please,

[gogasca]

Hi John,

Hope you are fine, can you upload the following:

deb ccsip mess

deb ip nat sip

sh ip nat translation (before and after a hold/resume)

debug voice ccapi inout

for every test,

MTP may work here...but we are working with a customer which is experiencing a similar problems and issue seems to be CUBE not updating a attribute field for active/inactive streams.

Thanks John

[cjrchoi11]

Hi Gonzalo,

Can you please take a look the attached 'debug ccsip all' and provide a clue? MoH server is located in CUCM but I cannot see a packet to update to SBC with MoH server IP address.

-CUBE is not using NAT

-192.168.15.11=CUBE

-192.168.15.173=CUCM, MoH server

-192.168.15.188=IP Phone

-207.245.2.12=SBC signal

-207.245.2.13=SBC media

Thanks,

John

[Nicholas Matthews]

Please make sure you have this command:

voice service voip

sip

midcall-signaling passthru

This is required for supplementary services on SIP-SIP CUBE.

-nick

[cjrchoi11]

No luck with 'midcall-signaling passthru'

As per CUBE configuration guide,

http://www.cisco.com/en/US/partner/docs/ios/voice/cube/configuration/guide/vb-gw-overview.html#wp1086330

-Media Mode > Media flow around > SIP-SIP=yes (*notes. SIP-to-SIP support is limited to basic audio calls)

-Supplementary Services > MoH > SIP-SIP=yes

Is it meaning 'supplementary services' which includes MoH are not support in 'flow-around' mode?

I really need to know the CUBE capability in my environment.

-No MTP in CUCM - Delay Offer. I have many SRST sites and not want to anchor MTP which requires extra cost and this makes another issue when implement g729 with carrier SBC since it requires transcoder (MTP is g711 only)

-CUBE - Delay offer. I can confiure EO but it makes uni-directional issue (when DO-EO mixed) so I must DO.

Again, everything okay if I configure MTP in CUCM or 'flow-through' in CUBE but I need to know whether my requirement feasible.

Thanks,

John

[Nicholas Matthews]

Hi John,

Not sure if it I fully understand everything you're trying to ask, but I'll give it a shot:

MTP is supported for G711 and G729. Use a software MTP on a router via 'max sessions software' with 'codec g729r8' to accomplish this.

MoH is considered a supplementary service because it is directly tied to hold/resume which are the very basics of supplementary services.

If you do not want a MTP for a SIP-SIP cube for early offer, you will need to do DO-EO with the 'early-offer forced' command. This was implemented into 12.4(20)T.

If you receive an EO call it will complete EO-EO without MTP fine.

hth,

nick

[cjrchoi11]

Hi Nick,

Let me make simple my requirement

-No MTP in Call Manager (DO)

-'flow-around' mode in CUBE (DO or EO)

what I found is MoH doesn't work with the above condition. Do you think it should work?

John

[Nicholas Matthews]

Hi John,

If you're doing flow-around mode it is nearly the same thing as if you had a direct trunk from CUCM. This means that the normal CUCM without CUBE restrictions apply, which means you will need a MTP for supplementary services.

hth,

nick

[cjrchoi11]

Hi Nick,

I tested two cases. the difference is with CUBE and bypass CUBE with exactly same configuraiton in CUCM and SBC

1) CUCM(no MTP) - SBC, MoH works okay

2) CUCM(no MTP) - CUBE(flow-around mode, DO or EO) - SBC, MoH not works.

my understaning from your explanation is case1 if I configure CUBE 'flow-around' mode.

Can I understand 'No supplementary services when I configure CUBE flow-around with no MTP in CUCM'?

Thanks,

John

[Nicholas Matthews]

Hi John,

That sounds like unexpected behavior. That will probably require looking at a fairly large number of debugs and probably some packet captures.

We had some problems similar to this with the midcall-signaling passthru command, and it may have some problems with flow-around mode.

I would suggest opening a TAC case on this.

-nick