09-09-2016 12:35 PM - edited 03-18-2019 12:07 PM
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
09-09-2016 01:48 PM
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
09-09-2016 11:06 PM
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???
09-10-2016 11:40 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide