03-24-2008 10:58 PM - edited 03-15-2019 09:37 AM
I have a sip provider i'm trying to makes calls OUT to from a CUCM, via a CUBE...
On outbound calls i'm getting this message in a trace -- the destination phone on the other side of hte PSTN rings once -- but that's it, and right after it rings the caller on the CUCM get's a fast Busy..
Disconnect Cause (CC) : 65
Disconnect Cause (SIP) : 487
Solved! Go to Solution.
03-26-2008 11:30 AM
The SIP side looks okay to me, although i'm more used to looking at SIP messages in Ethereal / Wireshark. From the h245 debug it looks like CCM is dropping the call for whatever reason:
Mar 26 18:17:19.792: //230/80C4B6C10400/H323/cch323_run_h245_cap_in_sm: Received H245_EVENT_CAP_REJECT while at state AWAITING_RESPONSE
Regards,
Jonathan
03-25-2008 04:31 PM
Here are some things to double check:
1. Make sure that you have the voice codec profile applied to the matching dial-peer. G711ulaw, though default within a CME environment, must be specifically named as the codec when sending or you'll have those issues.
voice class codec
codec preference 1 g711ulaw
dial-peer voice 10 voip
voice-class codec 1
03-26-2008 08:30 AM
03-26-2008 08:35 AM
On your H.323 Gateway in Call Manager , do you have:
Media Termination Point Required
Wait for Far End H.245 Terminal Capability Set
Fast start enabled inbound and Outbound?
(do you have MTPs available)
03-26-2008 10:13 AM
MTP's are in, via hardware DSP's in the gateway and they are being used, confirmed with show sccp connections.
MTP is enabled, fast start in and out is also on, with G711ulaw,
Wait for Far End - tried both ways - no difference
From my own trace what I can see is that the ISR is cancelling the call for some reason -- the code points to codec -- but I don't see what the codec issue is.
03-26-2008 10:15 AM
What version of Call Manager are you running?
03-26-2008 10:35 AM
6.0.1
03-26-2008 10:46 AM
Could be something to do with the RTP parameters CUBE is passing onto CallManager. As soon as your SIP provider sends you 183 with SDP (I assume the following! - can you provide h323 debugs?) CallManager is dropping the call and the CUBE sends a CANCEL to the SIP provider.
Have a look at: http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps5640/prod_white_paper0900aecd8067937f.html
and
http://www.cisco.com/en/US/docs/ios/voice/cube/configuration/guide/vb-gw-h323sip.html
For some tips.
Are you using media flow around or flow through? Anything interesting in the CallManager traces?
Regards,
Jonathan
03-26-2008 11:05 AM
Sorry didn't realise you were using CCM6, have you tried a SIP trunk to the CUBE?
Assume you're currently using h323 because in the SIP debug I only see the SIP provider side of the call, and h323 has been mentioned by previous respondents.
Regards,
Jonathan
03-26-2008 11:10 AM
Don't have CCM traces - which ones would be relevant?
H323 I can also pickup, I went through the cube document and everything seems right to me. Where do I check the media flow around vs flow through? and where would I set that?
I could use SIP trunk - however the gateway was already setup for other things (access to REAL PSTN via VIC cards) so I figured I could keep it.
03-26-2008 11:24 AM
For traces I'd start with CallManager, make sure at least h225, h245 and MTP are enabled. Possibly also IP Voice media streaming app.
You're probably using media flow through which is the default, unless you've configured 'media flow-around' in a dial-peer, global config or a voice class.
h323 debugs and CCM traces would probably be most helpful at this point.
Should be no problem sticking with h323, are there any firewalls or access lists between CCM and CUBE? Are your MTPs on the same router as CUBE? Traces will help show if the correct MTP is being selected and hopefully why the call is failing.
Regards,
Jonathan
03-26-2008 11:21 AM
Here is the H245
I find it interesting looking at the fields in the SIP messages...
Here is what I sent to the provider...
v=0
o=CiscoSystemsSIP-GW-UserAgent 4205 4127 IN IP4 MY-IP-ADDRESS
s=SIP Call
c=IN IP4 MY-IP-ADDRESS
t=0 0
m=audio 19108 RTP/AVP 0 101 19
c=IN IP4 MY-IP-ADDRESS
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
and here is what they sent... I wish I had more knowledge how to read them, I mean I can see the PCMU/8000 but the rest of it I cannot follow...
v=0
o=root 25690 25690 IN IP4 PROVIDERIP
s=session
c=IN IP4 PROVIDER IP
t=0 0
m=audio 12630 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=nortpproxy:yes
03-26-2008 11:30 AM
The SIP side looks okay to me, although i'm more used to looking at SIP messages in Ethereal / Wireshark. From the h245 debug it looks like CCM is dropping the call for whatever reason:
Mar 26 18:17:19.792: //230/80C4B6C10400/H323/cch323_run_h245_cap_in_sm: Received H245_EVENT_CAP_REJECT while at state AWAITING_RESPONSE
Regards,
Jonathan
03-26-2008 11:35 AM
So perhaps a SIP trunk between the 2 may fix the problem.
Wonder if that will fix my funny DTMF issues as well.
03-26-2008 11:59 AM
Well -- switching to a SIP trunk fixed the problem. So it was something in the H323 config that was messing me up..
Time to see if it fixes my DTMF issues too..
-- update... Fixed my DTMF issues too (had to turn OFF the MTP)
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: