Regarding incoming dial peer

[Vivek Batra]

Hi,

Got below para from one of the Cisco document, does seems' contradictory?

--------------------------------------------------------------------------------------------------

Special Note on POTS Calls with Empty Calling Number Field

Assume this configuration:

dial-peer voice 1 pots
destination-pattern 9T
port 1/0:1
Now, assume that an incoming call arrives with no calling number information and is matched with the POTS dial peer based on the destination-pattern 9T command. In this case, the Cisco IOS router or gateway uses the "9" digit as the calling number and forwards the call to the corresponding device, such as CallManager or the IOS Gateway. In order to not replace the empty calling number field, create a dummy POTS dial peer with just the incoming called-number command configured. Because the incoming called-number statement has higher priority than destination pattern for inbound POTS matching, dial-peer voice 2 becomes the POTS dial peer used.

dial-peer voice 1 pots 
destination-pattern 9T
port 1/0:1
!
dial-peer voice 2 pots
incoming called-number .

-------------------------------------------------------------------------------

So in the above example (when incoming called-number command is not configured), how destination-pattern 9T command can be matched against empty calling number as in my opinion, destination-pattern 9T command for inbound call should match the ANI which should be prefixed at least with "9" whereas in the example, ANI is blank.

May be I'm skipping some words in between.

Thanks

Vivek

[Chris Deren]

Vivek,

Have you read this:

http://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/14074-in-dial-peer-match.html

If you have no called number, but calling number then destination-pattern will be matched based on the calling number vs. called number, this is slightly confusing but that is the way dial-peers work as explained in the document.

[Vivek Batra]

Hi Chris,

Yes, this is the document I referred before.

I do agree with the case you wrote.

However, If you again look at the example which I quoted before, it's about blank ANI, not blank DNIS. Now how destination-pattern 9T (eventually respective dial-peer) can be selected when call is having empty ANI b/c destination-patter for incoming call leg matches calling number and ANI is blank in this case. This seems contradictory to me.

Before configuring in productive environment, I thought to verify the same.

[Aaron Harrison · Accepted solution]

Hi

I don't believe it would match - if there's no calling number then it wouldn't match 9T.

What it may well do is match the 'port' setting on the dial peer. This is the last dial-peer match criteria for inbound peers.

Once that inbound peer is matching, the number associated with dest-pattern may be applied in place of the blank calling number... but that doesn't mean that the destination pattern created the match to that peer in the first place. Chicken and egg...

If you have two voice-ports, prove it by setting a different destination pattern on each peer, with each peer pointed at different ports. I bet it would put the destination-pattern in as the ANI based on the port originating the call.

Regards

Aaron

[Vivek Batra]

Hi Aaron,

Yes, you are right and clear to me too.

The specific line viz 'is matched with the POTS dial peer based on the destination-pattern 9T command' was forcing me to think how empty ANI can match the dial-peer on the basis of destination-pattern 9T command. Now I do understand that respective dial peer is being selected on the basis of port configured, not on the basis of destination-pattern 9T command. That line in my opinion should be 'is matched with the POTS dial peer based on the port 1/0:1 command'.

Further, yes once dial-peer has been selected on the basis of port 1/0:1 (in my case), destination-pattern 9T is forcing to pass only 9 as ANI. To avoid this viz to pass complete ANI, another dial-peer with incoming-called number. is configured to match inbound call leg and hence to pass complete ANI.

Thanks

Vivek

[Aaron Harrison]

Hi Vivek

No problem.. I agree, the document seems incorrectly worded.

Please remember to rate replies and mark as 'answered' when appropriate to highlight useful content.

Aaron

[Vivek Batra]

Yes, sure I will do onwards.

[Carlo Poggiarelli · Accepted solution]

Hi.

In matching criteria, we need to include also the port where an incoming call comes from.

So in your case, without any specified incoming called number, the incoming port is matched.

You have also to consider that from IOS 15.1 , direct-inward-dial is enabled by default.

HTH

Regards

Carlo

[Vivek Batra]

Hi Carlo,

Now I got that in my example quoted in first thread, dial peer is being selected on the basis of port command, not destination-pattern command as ANI is blank. Only one statement in Cisco doc forced to think in other way, unnecessarily :)

You have provided very useful information about DID command for new version.

Thanks

Vivek