cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1903
Views
10
Helpful
6
Replies

CUBE Dial-Peer Looping Prevention

Mustain
Level 1
Level 1

Hi Good People,

 

Hope someone here can help me solve my problem. I have problems with the process of incoming calls (FAX and Voice), but for outgoing calls it is normal. So, the condition is when an incoming call is received with dial-peer 200, for example, this must be re-invited to ITSP with dial-peer 201, but I don't know why CUBE sends an Invite to ITSP with dial-peer 301. If I disable dial-peer 301, the call will work fine for incoming or outgoing.

 

I attached the debug output and the configuration of my CUBE.

1 Accepted Solution

Accepted Solutions

In general I would recommend you to follow these guidelines to avoid loops.

  • Make sure that your configuration for outbound and also inbound dial-peers do not have any overlaps in match or call routing.
  • For inbound dial-peer matching use a more specific match criteria then calling or called numbers.
    • If the inbound call leg is voip I would for the most recommend use VIA header information to match the inbound direction as that's the first matched criteria.
  • Use either CoS or DPG to define the allowed path via the inbound to outbound dial peer(s).

For more information on how dial peer matching works in IOS have a look at this excellent document.



Response Signature


View solution in original post

6 Replies 6

Hi,

 

There are no debugs in attached file. 

 

Are you trying to loop the incoming call back to ITSP without sending it to CUCM?

 

I guess the problem here is an incoming translation pattern on dial-peer 200. When call is received on dial-peer 200, your incoming number 02129973[012].. would be translated to either 0xx, 1xx or 2xx because of below translation. 

 

 

dial-peer voice 200 voip
description *** Inbound Dialpeer For Telkom | 02129973000 ***
translation-profile incoming Inbound-WSPI1-TELKOM 

 

voice translation-profile Inbound-WSPI1-TELKOM
translate called 300

 

voice translation-rule 300
rule 1 /^021299730\(..\)$/ /0\1/
rule 2 /^021299731\(..\)$/ /1\1/
rule 3 /^021299732\(..\)$/ /2\1/

 

Your test call might have translated to 19x hence it matched dial-peer 301

 

dial-peer voice 301 voip
description *** Outbond Dialpeer For Telkom | 02129973[34]xx ***
translation-profile outgoing Outbond-WSPI2-TELKOM
destination-pattern 19T

 

If you want to hairpin this call back to ITSP via dial-peer 201 then you need to prefix 9 in front of calling number, using translation rule. 

 

dial-peer voice 201 voip
description *** Outbond Dialpeer For Telkom | 02129973xxx ***
translation-profile outgoing Outbond-WSPI1-TELKOM
destination-pattern 9T

 

Make sure you are aware of the purpose of all existing dial-peers so that you don't break any other incoming or outgoing calls.

 

 

Regards,

Onkar Mahajan

 

Please rate if helpful

Thanks for your comment,

I've actually finished this configuration on the other hand, and I can't see the same problem with this one. Both incoming / outgoing calls are normal.

Hi Onkar,

 

Sorry, here is the debug output.

Debugs shows that the incoming dial-peer 300 was selected, which has incoming translation-profile 'Inbound-WSPI2-TELKOM' so original number 02129973399 was translated to 399 

 

Mar 12 17:42:16.777: //-1/72AE5A5F9E01/CCAPI/cc_api_call_setup_ind_common:
Interface=0x7FCC3633ADC8, Call Info(
Calling Number=085726275712,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=02129973399(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=300, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=170305

 

Then pattern 399 was matched to outgoing dial-peer 502 and looks like was an outgoing transition-profile on dial-peer 502 which translated 399 to a blank number.

(This dial-peer is missing on the config file you shared earlier, so I am guessing)

 

Mar 12 17:42:16.780: //170305/72AE5A5F9E01/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x7FCC3633ADC8, Interface Type=3, Destination=, Mode=0x0,
Call Params(Calling Number=02129973799,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=502, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)

 

Because of blank called number it failed. So CUBE tried next matching dial-peer 103 (with destination-pattern ...)  and sent the call to CUCM

 

You will have to modify dial-peers/translation-patterns depending on what you are trying to achieve.

 

Regards,

Onkar Mahajan

 

Please rate if helpful

 

 

In general I would recommend you to follow these guidelines to avoid loops.

  • Make sure that your configuration for outbound and also inbound dial-peers do not have any overlaps in match or call routing.
  • For inbound dial-peer matching use a more specific match criteria then calling or called numbers.
    • If the inbound call leg is voip I would for the most recommend use VIA header information to match the inbound direction as that's the first matched criteria.
  • Use either CoS or DPG to define the allowed path via the inbound to outbound dial peer(s).

For more information on how dial peer matching works in IOS have a look at this excellent document.



Response Signature


Problem solved, I changed the DP with a certain pattern. Thank you for saving my day.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: