[cisco-voip] H323 GW configuration
Kin Wai
kinwai at singnet.com.sg
Fri Feb 19 10:41:43 EST 2010
Hi Andrius,
I created the following,
voice translation-rule 2
rule 1 /^65\(...\)/ /\1/
!
voice translation-profile stripTechPrefix
translate called 2
!
dial-peer voice 20 voip
translation-profile incoming stripTechPrefix
destination-pattern 6.T
session target ras
!
RTR01#test voice translation-rule 2 65117
Matched with rule 1
Original number: 65117 Translated number: 117
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none
Debug shows
006457: *Feb 19 23:36:31.396 SGP: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
Result=SUCCESS(0)
List of Matched Outgoing Dial-peer(s):
1: Dial-peer Tag=20
006458: *Feb 19 23:36:31.396 SGP: //-1/00040F00C4B5/DPM/dpMatchPeersCore:
Calling Number=, Called Number=65117, Peer Info Type=DIALPEER_INFO_SPEECH
006459: *Feb 19 23:36:31.396 SGP: //-1/00040F00C4B5/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=65117
006460: *Feb 19 23:36:31.396 SGP: //-1/00040F00C4B5/DPM/dpMatchPeersCore:
Result=Success(0) after DP_MATCH_DEST
006461: *Feb 19 23:36:31.396 SGP: //-1/00040F00C4B5/DPM/dpMatchPeersMoreArg:
Result=SUCCESS(0)
List of Matched Outgoing Dial-peer(s):
1: Dial-peer Tag=20
006462: *Feb 19 23:36:31.396 SGP:
//-1/xxxxxxxxxxxx/CCAPI/cc_update_feature_vsa:
006463: *Feb 19 23:36:31.396 SGP: : updating existing feature vsa
006464: *Feb 19 23:36:31.396 SGP:
//-1/xxxxxxxxxxxx/CCAPI/cc_update_feature_vsa:
006465: *Feb 19 23:36:31.396 SGP: feature call basic
006466: *Feb 19 23:36:31.396 SGP: //112/00040F00C4B5/CCAPI/ccCallDisconnect:
Cause Value=3, Tag=0x0, Call Entry(Previous Disconnect Cause=0,
Disconnect Cause=0)
006467: *Feb 19 23:36:31.396 SGP: //112/00040F00C4B5/CCAPI/ccCallDisconnect:
Cause Value=3, Call Entry(Responsed=TRUE, Cause Value=3)
006468: *Feb 19 23:36:31.396 SGP:
//112/00040F00C4B5/CCAPI/cc_api_get_transfer_info:
Transfer Number Is Null
006469: *Feb 19 23:36:31.412 SGP:
//112/00040F00C4B5/CCAPI/cc_api_call_disconnect_done:
Disposition=0, Interface=0x48B09774, Tag=0x0, Call Id=112,
Call Entry(Disconnect Cause=3, Voice Class Cause Code=0, Retry Count=0)
006470: *Feb 19 23:36:31.412 SGP:
//112/00040F00C4B5/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent
Regards,
Kin Wai
-----Original Message-----
From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Andrius Kislas
Sent: Friday, February 19, 2010 6:03 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] H323 GW configuration
I would say on local gateway on incoming dial peer for called number
strip '65' using translation profile.
Andrius
On 2010.02.19 11:28, Kin Wai wrote:
> It's hitting dial peer 20 but not going anywhere. It's my first time
> doing GW/GK configuration, therefore I'm not sure whether it's normal
> behavior or not.
>
> So far, I got it working by either
>
> 1) using "num-exp 651.. 1.."
>
> 2) in ephone-dn , number 117 secondary 65117
>
>
>
> Is this the correct way? Or there should be a better way to do it? I
> tried to apply the translation-profile in dial-peer 20, to strip away
> the tech prefix "65" but it's not working somehow.
>
>
>
> _Below is the output when it's not working. _
>
> 005967: *Feb 19 17:14:25.894 SGP:
> //-1/00040F00C420/DPM/dpAssociateIncomingPeerCore:
>
> Calling Number=, Called Number=65117, Voice-Interface=0x0,
>
> Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search
> Type=PEER_TYPE_VOICE,
>
> Peer Info Type=DIALPEER_INFO_SPEECH
>
> 005968: *Feb 19 17:14:25.898 SGP:
> //-1/00040F00C420/DPM/dpAssociateIncomingPeerCore:
>
> Result=NO_MATCH(-1) After All Match Rules Attempt
>
> 005969: *Feb 19 17:14:25.898 SGP:
> //-1/00040F00C420/DPM/dpAssociateIncomingPeerCore:
>
> Calling Number=, Called Number=65117, Voice-Interface=0x0,
>
> Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search
> Type=PEER_TYPE_VOICE,
>
> Peer Info Type=DIALPEER_INFO_SPEECH
>
> 005970: *Feb 19 17:14:25.898 SGP:
> //-1/00040F00C420/DPM/dpAssociateIncomingPeerCore:
>
> Result=NO_MATCH(-1) After All Match Rules Attempt
>
> 005971: *Feb 19 17:14:25.910 SGP:
> //-1/00040F00C420/DPM/dpAssociateIncomingPeerCore:
>
> Calling Number=, Called Number=65117, Voice-Interface=0x0,
>
> Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search
> Type=PEER_TYPE_VOICE,
>
> Peer Info Type=DIALPEER_INFO_SPEECH
>
> 005972: *Feb 19 17:14:25.910 SGP:
> //-1/00040F00C420/DPM/dpAssociateIncomingPeerCore:
>
> Result=NO_MATCH(-1) After All Match Rules Attempt
>
> 005973: *Feb 19 17:14:25.914 SGP: //-1/00040F00C420/DPM/dpMatchPeersCore:
>
> Calling Number=, Called Number=65117, Peer Info
Type=DIALPEER_INFO_SPEECH
>
> 005974: *Feb 19 17:14:25.914 SGP: //-1/00040F00C420/DPM/dpMatchPeersCore:
>
> Match Rule=DP_MATCH_DEST; Called Number=65117
>
> 005975: *Feb 19 17:14:25.914 SGP: //-1/00040F00C420/DPM/dpMatchPeersCore:
>
> Result=Success(0) after DP_MATCH_DEST
>
> 005976: *Feb 19 17:14:25.914 SGP:
//-1/00040F00C420/DPM/dpMatchPeersMoreArg:
>
> Result=SUCCESS(0)
>
> List of Matched Outgoing Dial-peer(s):
>
> 1: Dial-peer Tag=20
>
> 005977: *Feb 19 17:14:25.914 SGP: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
>
> Calling Number=65117, Called Number=65117, Peer Info
> Type=DIALPEER_INFO_SPEECH
>
> 005978: *Feb 19 17:14:25.914 SGP: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
>
> Match Rule=DP_MATCH_DEST; Called Number=65117
>
> 005979: *Feb 19 17:14:25.914 SGP: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
>
> Result=Success(0) after DP_MATCH_DEST
>
> 005980: *Feb 19 17:14:25.914 SGP:
//-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
>
> Result=SUCCESS(0)
>
> List of Matched Outgoing Dial-peer(s):
>
> 1: Dial-peer Tag=20
>
> 005981: *Feb 19 17:14:25.914 SGP: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
>
> Calling Number=65117, Called Number=65117, Peer Info
> Type=DIALPEER_INFO_SPEECH
>
> 005982: *Feb 19 17:14:25.914 SGP: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
>
> Match Rule=DP_MATCH_DEST; Called Number=65117
>
> 005983: *Feb 19 17:14:25.914 SGP: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
>
> Result=Success(0) after DP_MATCH_DEST
>
> 005984: *Feb 19 17:14:25.914 SGP:
//-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
>
> Result=SUCCESS(0)
>
> List of Matched Outgoing Dial-peer(s):
>
> 1: Dial-peer Tag=20
>
> 005985: *Feb 19 17:14:25.914 SGP:
> //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
>
> Calling Number=65117, Called Number=, Voice-Interface=0x0,
>
> Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search
> Type=PEER_TYPE_VOICE,
>
> Peer Info Type=DIALPEER_INFO_SPEECH
>
> 005986: *Feb 19 17:14:25.914 SGP:
> //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
>
> Result=Success(0) after DP_MATCH_ORIGINATE; Incoming Dial-peer=20
>
> 005987: *Feb 19 17:14:25.918 SGP: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
>
> Calling Number=, Called Number=65117, Peer Info
Type=DIALPEER_INFO_SPEECH
>
> 005988: *Feb 19 17:14:25.918 SGP: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
>
> Match Rule=DP_MATCH_DEST; Called Number=65117
>
> 005989: *Feb 19 17:14:25.918 SGP: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
>
> Result=Success(0) after DP_MATCH_DEST
>
> 005990: *Feb 19 17:14:25.918 SGP:
//-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
>
> Result=SUCCESS(0)
>
> List of Matched Outgoing Dial-peer(s):
>
> 1: Dial-peer Tag=20
>
> 005991: *Feb 19 17:14:25.918 SGP: //-1/00040F00C420/DPM/dpMatchPeersCore:
>
> Calling Number=, Called Number=65117, Peer Info
Type=DIALPEER_INFO_SPEECH
>
> 005992: *Feb 19 17:14:25.918 SGP: //-1/00040F00C420/DPM/dpMatchPeersCore:
>
> Match Rule=DP_MATCH_DEST; Called Number=65117
>
> 005993: *Feb 19 17:14:25.918 SGP: //-1/00040F00C420/DPM/dpMatchPeersCore:
>
> Result=Success(0) after DP_MATCH_DEST
>
> 005994: *Feb 19 17:14:25.918 SGP:
//-1/00040F00C420/DPM/dpMatchPeersMoreArg:
>
> Result=SUCCESS(0)
>
> List of Matched Outgoing Dial-peer(s):
>
> 1: Dial-peer Tag=20
>
>
>
>
>
> When it's working, using either of the method stated above, I
> encountered a new problem, no call progress tone.
>
> Debug dial-peer shows that it's going into dial-peer 200XX (those
> ephones), is there any way to get call progress tones?
>
>
>
> 005798: *Feb 19 17:07:21.842 SGP:
> //96/00040F00C41D/H323/cch323_process_set_mode: Setting inbound leg mode
> flags to 0x10F, flow-mode to FLOW_THROUGH
>
> 005799: *Feb 19 17:07:21.842 SGP:
> //96/00040F00C41D/H323/cch323_process_set_mode: Sending deferred CALL_PROC
>
> 005800: *Feb 19 17:07:21.842 SGP:
> //96/00040F00C41D/H323/cch323_do_call_proceeding: gw_id=1
>
> 005801: *Feb 19 17:07:21.842 SGP:
> //96/00040F00C41D/H323/cch323_do_call_proceeding: set_mode called so we
> can proceed with CALLPROC
>
> 005802: *Feb 19 17:07:21.842 SGP: //96/00040F00C41D/H323/run_h225_sm:
> Received event H225_EV_CALLPROC while at state H225_REQ_FS_SETUP
>
> 005803: *Feb 19 17:07:21.842 SGP:
> //96/00040F00C41D/H323/cch323_h225_set_new_state: Changing from
> H225_REQ_FS_SETUP state to H225_ACC_FS_CALLPROC state
>
> 005804: *Feb 19 17:07:21.842 SGP:
> //96/00040F00C41D/H323/generic_send_callproc: ====== PI = 0
>
> .
>
> ..
>
> 005834: *Feb 19 17:07:21.854 SGP:
> //-1/xxxxxxxxxxxx/H323/cch323_iev_queue_service: Dispatch 0x1 internal
> event to H225 SM
>
> 005835: *Feb 19 17:07:21.854 SGP: //96/00040F00C41D/H323/run_h225_sm:
> Received event H225_EV_ALERT while at state H225_ACC_FS_CALLPROC
>
> 005836: *Feb 19 17:07:21.854 SGP:
> //96/00040F00C41D/H323/cch323_h225_set_new_state: Changing from
> H225_ACC_FS_CALLPROC state to H225_ACC_FS_ALERT state
>
> 005837: *Feb 19 17:07:21.854 SGP:
> //96/00040F00C41D/H323/generic_send_alert: ====== PI = 0
>
> 005838: *Feb 19 17:07:21.854 SGP:
> //96/00040F00C41D/H323/cch323_get_embedded_obj_from_ccb: ccb=0x47A61E74,
> tag=17, size=83
>
> 005839: *Feb 19 17:07:21.854 SGP:
> //96/00040F00C41D/H323/cch323_get_embedded_obj_from_ccb: Extraction
> PASSED from 0x4B852B50
>
>
>
> Regards,
>
> Kin Wai
>
> * *
>
> * *
>
> *From:* Kevin Thorngren [mailto:kthorngr at cisco.com]
> *Sent:* Friday, February 19, 2010 6:01 AM
> *To:* Kin Wai
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] H323 GW configuration
>
>
>
> Maybe try "incoming called-number 65T" under dial peer 20 with your
> translation-rule. May the incoming call is hitting a different dial peer.
>
>
>
> Try looking at "debug voip dialpeer" to see what is happening with the
call.
>
>
>
> Kevin
>
> On Feb 18, 2010, at 3:38 PM, Kin Wai wrote:
>
>
>
> Hi,
>
> I'm have a gateway registered to Gatekeeper.
>
>
>
> Currently,
>
> Local call to remote sites through the GK --- OK
>
> Remote sites to PSTN through local gateway ---- OK (using the tech-prefix)
>
> Remote sites to Local Phone ----- NOT OK (using the same tech-prefix)
>
>
> I have the following configuration :
>
> dial-peer voice 20 voip
>
> destination-pattern 6.T
>
> session target ras
>
> !
>
> dial-peer voice 21 pots
>
> destination-pattern 65.T
>
> port 0/1/0:15
>
>
>
> **I have excluded the h323-gateway commands**
>
> The tech prefix for this site is 65
>
>
>
> What do I need to do in order for the remote site to call the local
> phones? The gatekeeper is a 3^rd party gatekeeper.
>
> I suppose there's no issue with the communications as remote sites user
> can make outgoing call to PSTN.
>
>
>
> Do I need to enable "allow connections h323 to h323" under voice service
> voip ? Or I need to create an additional dial-peer to cater for the
> local phones?
>
>
>
> I tried to apply translation-rule to strip away the tech-prefix or even
> make it the full DID number under dial-peer 20, but it still won't work.
>
>
>
> Anyone have any clue about this problem?
>
>
>
> Thanks in advance!
>
>
>
> Regards,
>
> Kin Wai
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
More information about the cisco-voip
mailing list