Dial-Peer problem

[tarun.pahuja]

One of my friends told me that the best way to configure a gateway connected to a PRI was as follows: asking controller 0/0 was connected to a PRI for voice. And the call manager IP address is 10.10.10.1.

Dial-peer voice 1 pots

destination pattern .T

Forward digits-all

port 0/0:23

dial-peer voice 2 pots

incoming called-number .

Direct-inward dialing

port 0/0:23

Dial-peer voice 20 voip

destination patter 1...

Session target ipv4:10.10.10.1

My question is as follows: I am confused why he used incoming called-number . for incoming calls. From what i know, incoming called-number would alwats take priority over destination-pattern, so when digits come to port 0/0:23, incoming called-number dial-peer would always be matched as it takes priority over destination pattern, then what is the point of having that dial-peer??? Any thoughts would be highly appreciates, also this configuration was referred to me for MGCP, would the same apply under H.323 senario as well.

Thanks

[arraman]

Hi,

Incoming called-number is mainly used in case if the trunk is mainly used to handle mostly incoming calls. This is mainly useful in case of Voice service provider, where he gives an access code to the customers to call-in, so irrespective of any destination the customer wants to dial, he dials the access code first.

Hope this helps you

Arun

[arraman]

Hi,

Incoming called-number is mainly used in case if the trunk is mainly used to handle mostly incoming calls. This is mainly useful in case of Voice service provider, where he gives an access code to the customers to call-in, so irrespective of any destination the customer wants to dial, he dials the access code first.

Hope this helps you

Arun

[dweiner]

There's an interesting interaction between dial-peers and caller-id when caller-id is not provided (for example with T1-CAS). If there is no caller-id, the router takes the first administered dial-peer and uses the destination pattern as the calling party number. In the case of an installation I worked on years ago, calls were coming in as "Call from 911" b/c the first pots dial-peer I administered had a destination pattern of 911. After that troubleshooting I have always, as the _first_ dial-peer administered, used a "dummy" dial-peer that used "incoming called-number ." to capture all calls, direct-inward-dialing if it was PRI, and the voice port. This then correctly provided "Call from (Unknown Number)" on phone displays.

These dial-peers only apply to H.323 - they are disregarded when MGCP is up. They will, though, apply when in SRST mode.

[sarmentrout.bok77]

HERE IS THE LONG ANSWER:

By Cisco concept, every call that traverses the router must match both an inbound and an outbound peer. This gets a little confusing and a lot of people that I have come across do not understand this process but I will attempt to do my best to convey it in writing.

First off, it is important to understand these concepts:

1. The 'incoming called-number' command matches based on the called party number and it does NOT play a role in where the call is routed. It is ONLY used to select the inbound peer.

2. The inbound peers responsibility is to dictate how the VoIP parameters (codec, dtmf relay, ip precedence, VAD, RSVP support, fax-rate, etc...) get set. It does NOT affect where the call is routed, but it does determine all the call properties for the VoIP side of the call, regardless of what outbound peer it terminates on.

3. The 'destination-pattern'command is ALWAYS used to match an outbound dial-peer.'

4. If a call comes in via VoIP, the method for inbound peer selection is as such; peer with incoming called-number, if none then peer with answer-address, if none then the calling party info is matched against the destination-pattern (Notice this is the calling party, or better yet, the person making the call.).

5. If a call comes in via POTS, the method for inbound peer selection is the same but with ONE addional possibility; the last selection is the inbound dial-peer is matched based on port configuration. The dial peer that is selected is the first dial peer in the configuration that specifies the port the call came in on.

6. If no inbound peer can be matched using any of the criteria listed in numbers 4 and 5 above, the inbound peer is set to peer ID 0 (zero). The characteristics are set as follows:

6a. For a inbound VoIP call: any supported codec, no dtmf relay, ip precedence 0, VAD-enabled, No RSVP support, and fax-rate voice.

6b. For an inbound POTS call: no application and no direct-inward-dial.

There are a large amount of voice issues on networks out there attributed directly to the lack of understanding of this principle. When the peer ID is matched to zero, there could be a mismatch in variables typcically codec, vad, and dtmf.

Now, one last note to reference:

The information above relates to an H.323 gateway environment. An MGCP gateway uses NO dial-peers as you PRI interface is backhauled to the CallManager and uses its route patterns to direct calling. UNLESS, you are relying on SRST. SRST directs the local router (gateway) to become the active callmanager and therefore would use dial-peers to direct traffic in/out of the PRI.

-----

To try and make things easier to follow and understand I have included a sample call from a TDM style interface (FXS) in my network (0105 called 1906). Please notice that one call matched two peers; one for incoming, the other for outgoing legs.

tul-913-15lewis#sho call active voice brief

3108 : 362730702hs.1 +1314 pid:105 Answer 0105 active

dur 00:00:57 tx:3520/563200 rx:2864/458240

IP 10.100.200.1:17224 rtt:7ms pl:52070/0ms lost:0/0/0 delay:64/64/65ms g711ulaw

3108 : 362730703hs.1 +1313 pid:1 Originate 1906 active

dur 00:00:57 tx:2865/458400 rx:3520/563200

Tele 1/0/0 (6836): tx:67030/6703/0ms g711ulaw noise:0 acom:39 i/0:-61/-46 dBm

Telephony call-legs: 1

SIP call-legs: 0

H323 call-legs: 1

MGCP call-legs: 0

Total call-legs: 2

tul-913-15lewis#

I hope this helps...

[tomchan]

Thanks for the clear explanation.

I got a bit confused on item number 3.

3. The 'destination-pattern'command is ALWAYS used to match an outbound dial-peer.'

Below is what I found from CCO.

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010fed1.shtml#topic12

The dial peer attribute destination-pattern has different behavior when applied to inbound or outbound call legs:

For inbound dial peers, the destination-pattern is matched against the calling number (ANI string).

For outbound dial peers, the destination-pattern is matched against called number (DNIS string).

Therefore, a dial-peer with the destination-pattern attribute may work for both outbound and inbound matching.

I think in this case, the destination pattern is used with DID. Other than that, I would treat "destination pattern" as ALWAYS to match an outbound dial-peer. Is that the case? pls advice.

[tomchan]

Have found more info for inbound DID...

Matching the Correct Inbound POTS Dial Peer for DID

For DID to work correctly, make sure the incoming call matches the correct POTS dial-peer where the command direct-inward-dial is configured. To match the correct inbound dial peer, we recommend using the dial peer command incoming called-number dnis_string under the DID POTS dial peer.

Other commands used to match dial-peers include: answer-address ani_string , destination-pattern string or port voice-port . The advantage of using the incoming called-number command is that every call has associated DNIS information (called-number) and it has priority over the previous commands.

If you do not use the incoming called-number command to match the inbound dial peer, consider the following:

If using ANI information to match the DID POTS dial-peer, make sure the command answer-address is configured correctly and the telco-switch is providing ANI information. Some ISDN providers and most T1 channel associated signaling (CAS), except Feature Group D (fgd), do not provide ANI information.

If answer-address is NOT matched against ANI, then the ANI may be matching the destination-pattern configured (for outbound dialing) under another POTS dial-peer. If the destination-pattern is matched against ANI, make sure that the command direct-inward-dial is configured under that dial-peer.

If the incoming DID call is not matched to an inbound POTS dial-peer based on incoming called-number or answer-address or destination-pattern or port, then default dial-peer 0 will be used. DID is disabled by default on dial-peer 0.