Dialpeer Issue

[hadisharifi]

Hi, we have a PBX connected to a SIP GW cisco 2811 router via E1, when a number is dialed from the PBX the GW only matches the first digit and tries to find a matching dialpeer to route the call and doesn't collect anymore digits and the user gets a busy tone.

Incoming dialpeer that is getting matched.

dial-peer voice 201 pots
destination-pattern 6...
incoming called-number .
direct-inward-dial
port 0/0/0:15
forward-digits all

Outgoing dialpeer to be matched once the four digits are recieved.

dial-peer voice 105 voip
destination-pattern 3[23]..
voice-class codec 1
session protocol sipv2
session target ipv4:10.24.4.74
dtmf-relay rtp-nte
no vad

The debug output shows:

Jun  3 02:32:59: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8  callref = 0x3046
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech 
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA1838E
                Preferred, Channel 14
        Facility i = 0x9FAA068001008201008B0100A1100201010201553008820301B850860101
        Facility i = 0x9FAA068001008201008B0100A116020102020100800E5061756C20537761696E62616E6B
        Progress Ind i = 0x8183 - Origination address is non-ISDN 
        Calling Party Number i = 0x0181, '6495'
                Plan:ISDN, Type:Unknown
        Called Party Number i = 0x81, '3'
                Plan:ISDN, Type:Unknown
        Shift to Codeset 4
        Codeset 4 IE 0x31  i = 0x80
Jun  3 02:32:59: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Calling Number=6495, Called Number=3, Voice-Interface=0x4562CFC4,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
Jun  3 02:32:59: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Result=Success(0) after DP_MATCH_ORIGINATE; Incoming Dial-peer=201
Jun  3 02:32:59: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Calling Number=6495, Called Number=3, Voice-Interface=0x0,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_FAX
Jun  3 02:32:59: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Result=NO_MATCH(-1) After All Match Rules Attempt
Jun  3 02:32:59: %ISDN-6-CONNECT: Interface Serial0/0/0:13 is now connected to 6495 N/A
Jun  3 02:32:59: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0xB046
        Channel ID i = 0xA9838E
                Exclusive, Channel 14
Jun  3 02:32:59: ISDN Se0/0/0:15 Q931: TX -> CONNECT pd = 8  callref = 0xB046
Jun  3 02:32:59: ISDN Se0/0/0:15 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x3046

[William Bell · Accepted solution]

Not my core area of expertise (E1s) but I am wondering if you configured overlap receiving on your ISDN interface (Serial 0/0/0:15 in your case).  My understanding is that some international carriers use overlap sending when outpulsing digits to PBX equipment (or voice gateways in your case).  With overlap sending, not all information elements are presented in the same call setup (versus en bloc which is what is used in domestic US).  Again, this is just my take.  I didn't see your serial interface configs.  You may want to take a quick peak at this document, it is a quick read:

http://www.cisco.com/application/pdf/paws/23382/isdn_overlap_prob.pdf

HTH.

Regards,
Bill

Please remember to rate helpful posts.

[hadisharifi]

Thanks for your help. That was it actually.

I should have mentioned that everything was working fine until yesterday when the GW was changed from an MGCP to SIP. Now the issue is with caller ID I don't see any caller ID either for calling or called party, that is their name don't show up where as before it used. Any ideas?

Thanks

[William Bell]

You may want to check out this link:

https://supportforums.cisco.com/message/356991#356991

It is a bit dated, but if you check out the tail end of @gogasca's response you will see some similarities to your scenario.

I know with H.323 GW there used to be an issue when the calling name was sent in the facility IE from the ISDN trunk.  That has been resolved and I don't think it was/is an issue with SIP.  I lean to the buffering issue @gogasca mentioned.

HTH.

Regards,
Bill