Outbound SIP to Provider

Answered Question
Mar 24th, 2008

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

Correct Answer by jonathan.dixon about 8 years 11 months ago

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



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
chadlincoln Tue, 03/25/2008 - 16:31

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

mdury Wed, 03/26/2008 - 08:35

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)

justincohen Wed, 03/26/2008 - 10:13

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.

mdury Wed, 03/26/2008 - 10:15

What version of Call Manager are you running?

jonathan.dixon Wed, 03/26/2008 - 10:46

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



For some tips.

Are you using media flow around or flow through? Anything interesting in the CallManager traces?



jonathan.dixon Wed, 03/26/2008 - 11:05

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.



justincohen Wed, 03/26/2008 - 11:10

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.

jonathan.dixon Wed, 03/26/2008 - 11:24

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.



justincohen Wed, 03/26/2008 - 11:21

Here is the H245

I find it interesting looking at the fields in the SIP messages...

Here is what I sent to the provider...


o=CiscoSystemsSIP-GW-UserAgent 4205 4127 IN IP4 MY-IP-ADDRESS

s=SIP Call


t=0 0

m=audio 19108 RTP/AVP 0 101 19


a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=rtpmap:19 CN/8000


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


o=root 25690 25690 IN IP4 PROVIDERIP



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 - - - -


Correct Answer
jonathan.dixon Wed, 03/26/2008 - 11:30

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



justincohen Wed, 03/26/2008 - 11:35

So perhaps a SIP trunk between the 2 may fix the problem.

Wonder if that will fix my funny DTMF issues as well.

justincohen Wed, 03/26/2008 - 11:59

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)

jonathan.dixon Wed, 03/26/2008 - 12:24

Good stuff :-) DTMF can be fun as well, but as you're using SIP to SIP hopefully RFC2833 DTMF will just work, although your provider may support out of band methods such as SIP INFO as well.

All the best,


justincohen Wed, 03/26/2008 - 12:28

Yeah all the DTMF is RTP-NTE, however when I was doing H323-SIP on inbound the unity wouldn't recognize the DTMF's properly, I was using RTP-NTE on the SIP leg and H245-alpha on the H323 leg. Unity would just continually say "I do not recognize that as a valid entry" no matter which DTMF key you pressed -- it was weird.

Thanks for all the help


This Discussion