01-28-2011 07:06 AM - edited 03-16-2019 03:08 AM
Dear Cisco Community,
We have a Cisco Unified Communications Manager Express Version 4.2(0) that it is located in a remote site and uses a SIP trunk with an ITSP (udp 5060), in respect to the incoming/outgoing calls.
The configuration of the SIP trunk that operates normally is the following:
dial-peer voice 101 voip
description PSTN OUTGOING CALLS
translation-profile outgoing OUTGOING_NEW
destination-pattern .T
session protocol sipv2
session target ipv4:10.102.254.91:5060
session transport udp
dtmf-relay sip-notify h245-alphanumeric
codec g711alaw
fax rate 9600
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw
no vad
!
dial-peer voice 1 voip
description *** Incoming Calls ***
translation-profile incoming INCOMING_NEW
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target ipv4:10.102.254.91:5060
session transport udp
incoming called-number .T
dtmf-relay rtp-nte
codec g711alaw
fax rate 9600
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw
Everything seems to be working normally, such as transfer of calls to external parties via the ITSP, or conference via MeetMe service of the CALL MANAGER EXPRESS.
This Call Manager Express communicates, amongst others, with a Cisco Unified Call Manager 6.1.3 on another site. The problem is that when somebody from the CME site tries to join externally on a Meetme that is initiated from the CUCM6.1.3 ( (calling from outside the company the direct extension that is forwarded to MeetMe #) gets rejected.
Example:
1) CUCM user initiates Meetme 6895
2) CME users from office join successfuly calling 5536
ephone-dn XX
number 5536
description fwd to Meetme6895
call-forward all 6895
hold-alert 30 originator
!
3) However, when a client/user wants to call the direct extension of the 5536 to join the MeetMe, the call is rejected.
dial-peer voice 11 voip
preference 1
destination-pattern 6[1-9]..
session target ipv4:10.2.1.250
dtmf-relay h245-alphanumeric
codec g711alaw
ip qos dscp cs5 media
no vad
!
dial-peer voice 12 voip
preference 2
destination-pattern 6[1-9]..
session target ipv4:10.2.1.251
dtmf-relay h245-alphanumeric
codec g711alaw
ip qos dscp cs5 media
no vad
any ideas?
Attached you may find the "debug ccsip calls" "debug ccsip messages"
many thanks in advance,
S
01-28-2011 08:07 AM
Can you try the following command "no notify redirect" globally or per dialpeer on GW.
01-28-2011 09:45 AM
Unfortunatelly no luck,
!
dial-peer voice 101 voip
description PSTN OUTGOING CALLS
translation-profile outgoing OUTGOING_NEW
destination-pattern .T
no notify redirect ip2ip
session protocol sipv2
session target ipv4:10.102.254.91:5060
session transport udp
dtmf-relay sip-notify h245-alphanumeric
codec g711alaw
fax rate 9600
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw
no vad
!
dial-peer voice 1 voip
description *** Incoming Calls ***
translation-profile incoming INCOMING_NEW
no notify redirect ip2ip
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target ipv4:10.102.254.91:5060
session transport udp
incoming called-number .T
dtmf-relay rtp-nte
codec g711alaw
fax rate 9600
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw
I did the same at voice service voip, but no result.
Just to comment that even that i issued "no notify redirect ip2pots" command, this was not shown in the running config.
Any other suggestions?
Kind regards,
S
02-01-2011 07:40 AM
Part of the output of the "debug ccsip messages" is the following:
Feb 1 16:12:22.513: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 480 Temporarily Not Available
Via: SIP/2.0/UDP 10.102.254.91:5060;branch=z9hG4bKafhbeg002gn1m35ku700.1
From: <00306956332125>;tag=cc59bfe9-CC-23
To: <029335536>;tag=C058A050-987
Date: Tue, 01 Feb 2011 14:12:01 gmt
Call-ID: a085d34003d603ba2475004d0162c955@Vivacom
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 1 INVITE
Allow-Events: telephone-event
Reason: Q.850;cause=18
Content-Length: 0029335536>00306956332125>
If I am not wrong cause 18 is used when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated.
Is there an option to change this period?
02-03-2011 04:05 AM
I have found a way to by-pass this error, by sending the voice call through the SIP trunk and not via the "toll-bypass".
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