hi, MM Thanks for your update about solving the issue. Rgds/Randy ... View more

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 ... View more

Hi, Nizar after reviewing the debugs and CUCM trace, 1.  The a=inactive issue was caused by CUCM,  it might be related to the transcoder being used as the MTP resource, please open a CUCM Sip issue TAC ticket to find the root cause, for the workaround, you can uncheck MTP required option in Sip trunk configuration in CUCM since the end point can use g.729 all the way to the ITSP via CUBE,right? 2. The other thing you can try,   Since CUCM sends a=inactive in SDP, the CUBE just passed on it to the ITSP, where the ITSP replied with 183 message in which the rtp port is 0, the CUBE released the call due to this rtp port 0,  you can use sip profile in CUBE to change a=inactive, or remove this line, try to see if the behavior from ITSP will be different. v=0 o=HuaweiSoftx3000 1073741826 1073741827 IN IP4 192.168.155.148 s=SipCall c=IN IP4 10.172.172.1 t=0 0 m=audio 0 RTP/AVP 0 101     <------  RTP port should not be 0 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=inactive Rgds/Randy ... View more

Hi,  Israel Thanks for your question. I wonder if you refer to SBC interface in ASR platform you mentioned. If it is the case,  since ASR 1K is a different infrastructure platform for CUBE function, even most of the command used for enterprise version of ASR is same as the ISR CUBE, the architeture is complete different.  The SBC interface will be only available at ASR platform, will not be available in ISR platform. Rgds/Randy ... View more

Hi, Nizar Please provide the following information, 1. show tech of the CUBE,   10.200.128.133 is the ip address for transcoder?  please provide related component's ip address. 2. "debug voip ccapi inout", "debug ccsip message" in one file for good, bad call 3.  "debug voip ccapi inout", "debug ccsip all" in one file for good, bad call 4.  the "a=inacive" is an issue, need to check CUCM trace to see why CUCM sending "a=inactive" 5. What is the ip phone model?  SIP, SCCP? 6.  the ptime error seems just warning,  the minimum ptime for g729 codec is 20ms in IOS. Rgds/Randy ... View more

Hi, Dan Thanks for your questions. 1.  For the request to enhance the performance of the router when combine CUBE feature with traditional  WAN/MPLS router plus other VPN encryption at the same router , our development team is working on the project. 2. For the large customer,  currently we recommend to seperate the funtion between CUBE and WAN router.  The sizing tool will be available when you consult your local System Engineer for the project. 3.  Again, the sizing tool with other features enabled at the same CUBE router like  MTP resource, VXML session termination will be available when you contact with your local System Engineer.  It related to company confidential policy, I can't reveal them here. Thanks for your understanding. Rgds/Randy ... View more

Hi, Micromedicreturns Thanks for your feedback. Regarding to your credential command under sip-ua confusion, please check the following feature which might help you, Configuring Multiple Registrars on SIP Trunks http://www.cisco.com/en/US/partner/docs/ios-xml/ios/voice/sip/configuration/15-1mt/Configuring_Multiple_Registrars_on_SIP_Trunks.html#GUID-BB6EE70E-1410-453A-A65E-91505345C8EB Rgds/Randy ... View more

Hi, Micromedicreturns Thanks for your questions. 1. since UC560 is not an officially supported platform for CUBE function, it will be only best effort for related function. 2. From technical point of view, if I understood correctly,  you got no way audio if SIP phones under Trixbox makes outgoing call to the ITSP while there is no issue when ITSP caller makes incoming calls to the SIP phones under Trixbox via UC560?  If the configruation is symmetric, then it is quite interesting for this asymmetric symptom. 3. For supported platform for CUBE, there was no such one trunk per router limitation. Rgds/Randy ... View more

Hi, Krishnan Thanks for your feedback. 1. box-box redundancy is active-standby mode, only the active box will process the calls 2. For load balancer, you can use Cisco Unified SIP Proxy (CUSP) to equally distribute the calls. Rgds/Randy ... View more

Hi, Nizar Nice to hear the issue was solved. 1. the INVITE message was fragmented due to the frame is bigger than the Ethernet's MTU 2. Actually it is ok to send this kind of big INVITE packet, from RFC 3261 it can be maximum 65,536 bytes. 3. Some versions of the Cisco IOS got the issue to reassembly this kind of  fragmented packet, that is why you need to use the workaround or upgrade the IOS. Rgds/Randy ... View more

Hi, Nizar Please attach "show tech" of the CUBE when you applied the workaround command. Rgds/Randy ... View more

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 ... View more

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 ... View more

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 ... View more

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 ... View more