I understand the idea of call survivability here; however, I am looking for a detailed mechanism for H323 call preservation. Need to understand how exactly it works. Will really appreciate if someone could share a good doc for it.
... View more
Thank you for the quick response.
Yeah its true that OOB utilizes SIP Notify messaging. However, my concern is that what will happen in situation when SIP trunk is configured as either below:
oob and rfc2833
Note: Party 1 supports OOB while Party 2 supports rfc2833
thanks in advance...
... View more
Need quick suggestion on the dtmf method usage for the below call follow:
PSTN >> PRI >> VG >> MGCP >> CUCM >> SIP Trunk >> CUBE
VG supports - OOB
CUBE supports - RFC2833
DTMF on SIP Trunk configured as:
No Preference: Will the trunk utilize OOB as the dtmf method as being supported by the VG??
RFC 2833: When VG sends dtmf as oob to cucm and SIP trunk has rfc2833 configured. What will happen in this case ? What will the dtmf flow ??
OOB and RFC2833: Which method would be selected and why. If OOB is selected by looking at the VG's dtmf method, then there would be the MTP requirement due to the mismatch. Please correct if I am wrong.
... View more
Can you please verify the dial-peer configs once again. Seems CUBE is unable to find / select the outbound dial-peer to route out the call which results in the SIP CANCEL message and hence a busy tone:
Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/info/2048/sipSPICheckAssertedIdC onfig: Dialpeer match is not yet done Jul 17 11:02:14.005: //-1/xxxxxxxxxxxx/SIP/Info/critical/4096/sipSPIGetContentGT D: No GTD found in inbound container Jul 17 11:02:14.005: //-1/xxxxxxxxxxxx/SIP/Info/critical/4096/sipSPIGetContentCS TA: No CSTA found in inbound container Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/verbose/4096/sipSPIUaddCcbToTabl e: Added to table. ccb=0x288953F0 firstname.lastname@example.org 01959700860 balance 1 Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/info/8192/sipSPIMatchSrcIpGroup: Match not found on carrier id Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/critical/8192/sipSPIMatchSrcIpGr oup: Match not found on Incoming called number: 01959700860 Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/critical/8192/sipSPIMatchSrcIpGr oup: Match not found on destination pattern: 9613400400 Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/info/12288/ccsipUpdateIncomingCa llParams: ccCallInfo: Calling name x, number 9613400400, Calling oct3 0x00, oct_ 3a 0x81, Called number 01959700860 Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/verbose/1024/sipSPIGetViaHostInU RLFormat: VIA URL:sip:172.16.145.3:5060, Host:172.16.145.3 Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/verbose/67584/sipSPIGetShrlPeer: Try match incoming dialpeer for Calling number: : 9613400400 Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/critical/1024/sipSPIGetFromCalle dPartyId: P-Called-Party-ID header not found Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/critical/1024/sipSPIGetPeerByCal ledPartyId: P-Called-Party-ID not found or parse error Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/critical/10240/sipSPIGetCallConf ig: No match found for P-Called-Party-ID Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/info/1024/ccsip_validate_and_upd ate_calling_info: PAI/PPI not configuredi for this dial-peer(2364), use RPID/FRO M header data Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/verbose/4096/sipSPIUpdateCalling InfoUsingRpidOrFrom: Updating Calling Info with FROM header data Jul 17 11:02:14.005: //-1/99AD0A000000/SIP/Info/info/2048/sipSPIGetCallConfig: P eer tag 2364 matched for incoming call
... View more
To get the issue surfaced, start step by step troubleshooting:
Ensure that the framing and line code settings match with the switch the gateway is attached to.
I could see slip sec error in the show controllers output which points to improper clocking configuration. Kindly ensure that one side of the connection is providing clock while the other is deriving clock from the line.
Check or replace your cables and, if necessary, ask your service provider to test the line. If the problem persists, there's always the possibility of bad hardware. If you have a second port to test with, try a different port to see if the problem resolves itself.
Once verified the physical layer connectivity / configurations, proceed further with the troubleshooting of the signaling channel, i.e., D-Channel:
Issue the command show isdn status
Ensure Layer 1 is Active; if not Active, then once again verify the controller as there is a problem with physical connectivity.
Ensure switch type is correctly configured to get MULTIPLE_FRAME_ESTABLISHED status under Layer 2.
From the q.921 debugs attached, it can be observed that the gateway transmits SABME message; however, never receives any UAf message from the other end. Kindly ensure that the D-channel is enabled on the equipment attached to the gateway. You might need to involve your service provider to get it verified for you.
You can verify if the SABME messages are indeed being transmitted out of the port by plugging a loopback plug into the T1/E1 port on the gateway. Be sure to change the clock to use the internal clock source and ensure that the controller comes up. Enable the debug isdn q921 and shut/no shut the controller again. After the gateway transmits the SABME message, it should get looped back toward the gateway, and the following message should appear:
RX <- BAD FRAME(0x00017F)Line may be looped!
If you see this message, everything is working correctly from the gateway's point of view. The gateway sees its own packet and marks it as a bad frame. This means the frame was sent out of the port, got looped by the loopback plug, and was received back by the gateway.
Once you are done troubleshooting the gateway / controller, you likely need to get your service provider involved.
... View more