SIP call loops between dial-peers

Unanswered Question
Mar 14th, 2010

Hi there,

we have CUCM7 "talking" to a CUBE router via SIP trunk; CUBE terminates SIP calls from a Telco:

CUCM --- CUBE --- SIP Provider

Calls to known extensions are handled fine whereas calls to unknown extensions loop between the dial-peers

for incoming and outgoing calls:

the relevant configuration is:

voice service voip
address-hiding
allow-connections sip to sip
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco
sip
  header-passing error-passthru
  no update-callerid
  midcall-signaling passthru
  privacy-policy passthru
  g729 annexb-all

    

dial-peer voice 100 voip
description *** Incoming SIP provider
destination-pattern 012345.%  <-- our phone number with DID/extensions
session protocol sipv2
session target ipv4:<IP-Address-of-CUCM>
incoming called-number 012345.%  <-- this entry has to be specified otherwise dial-peer isn't matched

                                                                            for incoming calls

voice-class sip asserted-id pai
voice-class sip privacy-policy passthru

dial-peer voice 200 voip
description *** Outgoing to SIP Provider
destination-pattern .T
session protocol sipv2
session target dns:<IP of SIP Provider>
voice-class sip asserted-id pai
voice-class sip privacy-policy passthru
voice-class sip early-offer forced
voice-class sip profiles 1

Problem: incoming call to unknown extension is catched by DP 100 but denied by CUCM causing CUBE to

route this call out to DP 200 (causing the SIP Provider to "reflect" the call back --> loop).

Is there an option to disable this kind of "hairpinning"?

Thank you in advance,

David

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
neharris Mon, 04/05/2010 - 17:23

Were you able to correct the problem?  If so how?

I'm seeing this too.  I don't think carrier thought about cases where NPA starts with a "9" and the NXX starts with a "9" (my case)

Aaron Harrison Tue, 04/06/2010 - 01:19

Hi

The easiest way to stop this sort of thing is usually to ensure that your number plan is not ambiguous - e.g. if you dial 9 to route externally, allow CCM to send the 9 out with the number.

On your gateway, only one dial-peer pointing out to the SP would match the leading 9, and you would then strip that out with a translation pattern (as it's not a POTS peer this won't happen automagically).

Your inbound-to-CCM peer should then match non 9 numbers.

Aaron

Please rate helpful posts..    

Actions

This Discussion

Related Content