Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

CME to CME Call forward all not working to External Number

Hi ,

 

I have an IP Telephony setup with 2 Call Manager Express version 9.x. Both are connected via VPN and we can make extension to extension calls.

 

The issue as follows.

 

Site B IP Phone(5270) call forward all to external number (933512183)where  9  is the access code.

 

from Site A user (3016)making calls to 5270 via VPN getting busy tone 

 

If site A user making calls with full number ie,17205270 the call is forwarding to the external number.

 

I have attached the working and non working debug voice ccapi inout logs.

Calling number =17103016,  called number=17205270.   Redirect number=933512183.9 is the access code.

 

I have checked the codec is g.711ulaw both the end.

 

Thanks in advance

Nithin Louis.

10 REPLIES

Please post your configs too

Please post your configs too.

Regards,

Andre

=====================

Please rate useful posts smiley

New Member

Hi Andre, Thanks for your

Hi Andre,

 

Thanks for your reply.

 

Please review the attached running configuration.

 

Site A IP address is 192.168.20.1 and Site B IP address is 192.168.1.253.

There is a dial peer voice 8 voip in site A which is used for trunk between site A  and Site B.

Regards

Nithin Louis.

New Member

Hi Everyone, The issue is not

Hi Everyone,

 

The issue is not resolved yet. Highly appreciated if you could help me for resolving this issue.

 

Regards

Nithin Louis.

VIP Gold

Hi Nithin,The issue is

Hi Nithin,

The issue is calling number for CME B, when you make a call from CME (dial- 17205270) then on CME B this call is coming taking dial-peer 2 (POTS) means from PSTN. But when you dial 5270 then call is coming on CME B using dial-peer 5252 (VOIP). So you need to add extra 9 when call i coming on CME B from CME A using 5252 voip dial-peer.

Try below configuration at CME B and then check. If no success then plz attach logs again for non working call.

voice translation-rule 10
 rule 1 /\(^1710....\)/ /9\1/


voice translation-profile cmebtocmea
 translate calling 10


dial-peer voice 5252 voip
 destination-pattern 1710[3-4]...
 session protocol sipv2
 session target ipv4:192.168.20.1
 incoming called-number .
 translation-profile incoming cmebtocmea
 dtmf-relay sip-notify
 codec g711ulaw
 no vad

 

Suresh

New Member

Hi Suresh, Thanks for your

Hi Suresh,

 

Thanks for your reply.

I have applied the config. which you suggested but no luck.

Please review the logs ,I can see that in the calling number 9 is append but call is not forwarding to the PRI (933512183).Where 9 is the access code.

I will explain the scenario briefly for your better understanding.

 

Site A dial plan is 17103xxx where the extension length is 4 ie for example 3016.

 

SIte B dialplan is 172052xx where the extension length is 4 ie for example 3016.

Each site have dedicated PRI connection.

They are connected site to site VPN. Users can make calls to extension to extension.

 

Example. From site A user (3016) making calls to site B (5270)and vice versa.

 

The issue is that when a user in site B Call fwd all to his mobile number (933512183) and user in site A calling to site B's extension getting busy.

 

The call fwd is working fine if any user calling from same site (ie,from site B) to 5270 the call is getting forwarded to the mobile number 933512183.I have attached that log also.Calling number 5275 ,Called number 5270. Fwd number 933512183.

 

Appreciate your help for resolving this.....

 

 

Can you post a debug isdn

Can you post a debug isdn q931 as well?

New Member

Hi Amine,  Please review the

Hi Amine,

 

 

Please review the attached file

 

 

 

 

Regards

Nithin Louis.

New Member

 

 

Here is your issue.

 

Jul 14 16:50:04.808: ISDN Se0/0/0:15 Q931: Sending SETUP  callref = 0x5AFF callID = 0xDA80 switch = primary-net5 interface = User 
Jul 14 16:50:04.812: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8  callref = 0x5AFF 
	Bearer Capability i = 0x8090A3 
		Standard = CCITT 
		Transfer Capability = Speech  
		Transfer Mode = Circuit 
		Transfer Rate = 64 kbit/s 
	Channel ID i = 0xA98394 
		Exclusive, Channel 20 
	Progress Ind i = 0x8183 - Origination address is non-ISDN  
	Calling Party Number i = 0x0180, '17205241' 
		Plan:ISDN, Type:Unknown 
	Called Party Number i = 0x81, '39747100' 
		Plan:ISDN, Type:Unknown
Jul 14 16:50:04.888: ISDN Se0/0/0:15 Q931: RX <- SETUP_ACK pd = 8  callref = 0xDAFF 
	Channel ID i = 0xA98394 
		Exclusive, Channel 20

 

Something wrong is been sent. You should not be getting a SETUP_ACK, thats where it goes wrong. For US you should be getting an Alerting, or another message right after your SETUP. SETUP_ACK is valid only when you are doing overlap sending, which is not your case.

 

Is this correct ?

 

	Called Party Number i = 0x81, '39747100' 
		Plan:ISDN, Type:Unknown

Don't you have to use a different Plan/Type combination? Arent you missing digits towards your carrier?

Most likely your Telco is

Most likely your Telco is rejecting the call because they see an outbound call from Site B PRI but the caller ID is not a number assigned to this Site:

Calling Party Number i = 0x2181, '917103016'<<<<< Site A number
Plan:ISDN, Type:National
Called Party Number i = 0xC1, '33512183'
Plan:ISDN, Type:Subscriber(local)

You can confirm this by calling your Telco and have them look at your call. If this is true, you can try to convince them to athorize such calls. The other option is to use Translation rules on the CME to manipulate the redirecting number.

Please rate helpful answers!

New Member

 Please provide debug isdn

 

Please provide debug isdn q931 for both working and not working scenarios. I suspect there's some header, probably redirecting_IE and its content is not liked by your carrier. Probably you will either have to strip the header, or modify it's content via a translation profile at the exit.

But first we need to see what information your are sending on the Q931 layer.

1095
Views
0
Helpful
10
Replies
CreatePlease login to create content