Hi ADAM,

thank you for your reply,

I have H323 GW added to CUCM in CUCM I enabled faststart for in-band and out band. and I checked require MTP.

regarding the codec I am using G.711 A law. So, I forced this in the dial-peers for incoming and outgoing.

in the CUBE I allowed all connections.

Do you think it is codec issue??

I can place outside calls the problem just in incoming calls.

regards,

Hi

It’s difficult to know what’s wrong without seeing the config or debug output, so here’s an example of a CUBE working from H323 to SIP.

In this example I have explicitly split the calls into four dial-peers. i.e.

Incoming calls from SP, outgoing call to CUCM

Incoming calls from CUCM, outgoing call to SP

In this example we’re going from a private network to a public network. We’re terminating and originating calls on the CUBE, so there’s no need for NAT.

!Generic config!

voice service voip

address-hiding

allow-connections h323 to sip

allow-connections sip to h323

voice class codec 1

codec preference 1 g711alaw

!

interface GigabitEthernet0/0

ip address 10.1.1.98 255.255.255.0

load-interval 30

duplex auto

speed auto

h323-gateway voip bind srcaddr 10.1.1.98

!

interface GigabitEthernet0/1

ip address 255.255.255.224

ip access-group 123 in ! ***** please see footnote

load-interval 30

duplex auto

speed auto

!

Incoming call from SP to CUCM

The SP is pre-fixing calls with AAA so we can easily identify where they’re coming from and be 100% sure which dial-peer is in use.

!

dial-peer voice 999 voip

description incoming SIP FROM SERVICE PROVIDER!

voice-class codec 1

voice-class sip asymmetric payload full

voice-class sip early-offer forced

session protocol sipv2

session target sip-server

session transport udp

incoming called-number AAA.+

dtmf-relay rtp-nte ! dtmf type used by SP

!

We now route the call to CUCM. We're taking the time to route any received DID to an extension 5001 for testing

We do this with a translation rule and an outgoing dial-peer

!

voice translation-profile 1001

  translate called 1001

!

voice translation-rule 1001

  rule 1 /.+/ /5001/

!

!

dial-peer voice 1001 voip

description H323 connection to CUCM

translation-profile outgoing 1001

preference 2

destination-pattern AAA123456789 !the DID sent by the SP.

b2bua

voice-class codec 1

session target ipv4:10.1.1.97 !CUCM

session transport tcp

dtmf-relay h245-alphanumeric !Our DTMF type

!

Outgoing call to SP

Again, To aid routing we’ve configured CUCM to pre-fix calls with a string. In this example we’re using the prefix ‘836204'

!

dial-peer voice 998 voip

description Incoming H323 from CUCM

b2bua

voice-class codec 1

incoming called-number ^836204.+

dtmf-relay h245-alphanumeric

!

! and now we route to SP

!

voice translation-profile CUCM_to_SP

translate called 10

!

voice translation-rule 10

rule 1 /^836204\(.*\)/ /\1/

!

dial-peer voice 5 voip

description Outgoing SIP TO SERVICE PROVIDER!

translation-profile outgoing CUCM_to_SP

destination-pattern ^836204.+

b2bua

voice-class codec 1

voice-class sip asymmetric payload full

voice-class sip outbound-proxy dns:SP's SBC

voice-class sip early-offer forced

session protocol sipv2

session target sip-server

session transport udp

dtmf-relay rtp-nte

!

sip-ua

sip-server dns.xxx

authentication xxx pass xxx realm xxx

access-list 123 permit ip to

access-list 123 permit udp to *****

*****Access list footnote *****

If you’re having media issues you could try allowing media traffic from to . Even though media is terminated on the CUBE's public IP and originated again on the private, I've seen examples where media is partially broken unless this is allowed.

eg access-list 123 permit udp ,

Try this as a last resort and if it works for you, please raise this with TAC because I'm sure it's not meant to be like this, but I’ve always been in a production environment with a customer when it’s cropped up.

Good luck.

Adam

Tank you too much for you help.

I saw the configuration that you sent I do not know if it is exactly what I did,

I made the conifguration vey simple for testing and later on I will add more configuration, belwo is my configuration:

voice service voip
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
h323    
  no h225 timeout keepalive
sip
  bind control source-interface GigabitEthernet0/1
  bind media source-interface GigabitEthernet0/1

interface GigabitEthernet0/0
description connected to SIP service provider

ip address

I did not create any translation rule for the time being, I just add the full 7-digit number to the IP phone as extension

dial-peer voice 100 voip

descrprtion for incoming calls from SIP Provider
destination-pattern 344....
session target ipv4:172.20.104.6

codec g711alaw
!

for ougoing calls this is one of the dial-peer:

dial-peer voice 110 voip
destination-pattern 07........
session protocol sipv2
session target ipv4:IP-address for the SIP provider
incoming called-number .
dtmf-relay rtp-nte
codec g711alaw
no vad

sip-ua
retry invite 5
retry notify 5
retry register 5
sip-server ipv4::IP-address for the SIP provider
host-registrar

if you need I can collect some debugs ,

agin thank you for your help

Hi,

Is  interface GigabitEthernet0/0 reachable by the SP?

it not get rid of the SIP bind commands.

BRB

I did not ask thm to ping it but for sure it is pingable because I can place and receive the calls, If I plcaed the calls then there is no issue so the reachability is there between me and SP

I tried to troubleshoot the problem with the provider and they said that after sending the invite message there is no reply from my side they can see ringing but the call not answered, at the end they receive error message which is 503.

I checked the 503 error message and it is mean Service un-available?

Any body know what is the meaning of service unavailable?

where I should look? and what  may cause the problem??

The 503's not telling you much, other than the other end isn't available.

With your scenario, there's a SIP dialogue that starts between the SP and the CUBE.

As soon as the initial SIP Invite hits the Cube, there's a similar but separate H323 dialogue that starts between the CUBE and CUCM, which hopefullys results in some RTP sockets being opened and a call completing

1. Make sure your IP connectivity is OK.

2. debug ccsip messages and confirm you have a working dialogue

3. similarly look at the h323 debug and look to see if anything stands out.

You could post some debug outputs...

Adam

Thank you Adam,

I solved the problem yesterday, It seems IOS problem

Excellent news.