cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
2858
Views
0
Helpful
3
Replies
John Mayer
Beginner

Incomming Calls on SIP Trunk Could not answer on Phones on CUCM

Hello Everybody

Actually i have a problem on our VOIP Network, we recently give SIP Trunk from out phone provider to Connect to PSTN

our voip network diagram are as below, we use Cisco2911 as voice gateway and CUCM 8.6 as Call Processing Server

PSTN (SIP Trunk)   <----> VG   <----> Phone (CUCM)

Outgoing calls from Phone (on cucm) are OK but we have issue with  Incoming calls from outside; phones are ringing but when phone pickups, other party still ringing and after some sec call disconnected.

for checking the incoming call, i set up Call Manager Express on VG with CIPC registered on it, try to call from outside, call is ok and both party can talk without any problem.

problem is only on phones which registered on CUCM, for solving the problem, i first check the codec between VG and CUCM and also the VG and SIP Provider all of the are G711ulaw

i enclosed the debug ccsip all

i appreciate the if you can help me to solve this issue

Thank you in Advance

John Mayer

Here is my SIP Trunk Config:

voice service voip
 no ip address trusted authenticate
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
 supplementary-service h450.12 advertise-only
 fax protocol t38 version 0 ls-redundancy 2 hs-redundancy 0 fallback pass-through g711ulaw
 no fax-relay sg3-to-g3
 h323
  no h225 timeout keepalive
  session transport udp
 sip
  bind control source-interface GigabitEthernet0/1
  bind media source-interface GigabitEthernet0/1
  min-se 300 session-expires 300
  registrar server
  early-offer forced


voice class uri 1001 sip
 host ipv4:10.105.40.34


dspfarm profile 11 transcode  
 codec g729abr8
 codec g729ar8
 codec g711alaw
 codec g711ulaw
 maximum sessions 20
 associate application SCCP
!
dspfarm profile 22 conference  
 codec g729br8
 codec g729r8
 codec g729abr8
 codec g729ar8
 codec g711alaw
 codec g711ulaw
 maximum sessions 2
 associate application SCCP
!         
dspfarm profile 33 mtp  
 codec g711ulaw
 codec pass-through
 maximum sessions software 500
 associate application SCCP


dial-peer voice 100 voip
 description "_Outgoing to CUCM_"
 destination-pattern [1-5]..
 session target ipv4:192.168.200.10
 dtmf-relay h245-alphanumeric
 codec g711ulaw
 no vad



dial-peer voice 200 voip
 description R_Incoming Call from SIP Trunk_S
 translation-profile incoming IncomingProfileSIP_1
 session protocol sipv2
 incoming called-number 43461...
 incoming uri via 1001
 dtmf-relay sip-notify rtp-nte
 codec g711ulaw
 no vad

3 REPLIES 3
Les Pruden
Enthusiast

Hi -

Your debug notes that the call is failing with a --> 503 Service Unavailable and a reason code of 47.   The debugs note that g711ulaw is negotiated in the UBE.  When the call sets up the phone rings but the RTP cannot be established because of a codec issue. 

You should check   --  the region configuration in CUCM to ensure g711 is configured -- check to ensure that the MRGL used by the SIP trunk includes a transcoder and MTP - compare the outbound call logs with this log to verify what codec is used for that successful call.

SIP/2.0 503 Service Unavailable
Reason: Q.850;cause=47

Hello Les Pruden

first of all thanks for your reply

and second, i already check the codec in region between Phone-CUCM, CUCM-VG and VG-SIP

all of them support G711ulaw

how can in config MTP, did you saw my config for mtp???

Looking at the log again I don't see the invite to CUCM so it does not look like a complete log.  I only see traffic between two IP addresses - 10.198.10.126 and 10.105.40.34.  

Get the initial invite from 10.105.40.34 which I assume is the service provider and 10.198.10.126 must be the gateway.  I don't see an invite to CUCM  - missing something here.

If I was working this issue the next steps for me would be :

1- turn off all debugs and then only set -- debug ccsip messages -- and place the ingress call again.  Verify that the gateway is sending an invite to CUCM and check the SDP etc.

2- for that same ingress test call pull the CUCM logs and see what error is happening as the called party picks up the phone.  The CM logs will show you where the error is.

You've only pulled part of the call path logs and need more information to fix this.  As you note, when the call stays in the gateway via your CME test it works so, the issue is with the interaction of the gateway and CUCM.  Pull the CUCM logs to see what it's having a problem with.

Content for Community-Ad

Spotlight Awards 2021