Support Center

FAQ

Filter
  • QHow To Configure SNMP Of MTG

    A

    1. Introduction

    What Is SNMP

    SNMP:  Simple Network Management Protocol. it used for network equipment management. The administrator (snmp server side ) obtains data/information from the device through snmp read operation (GET) and configure device through snmp write operation (SET). The device notifies the device of important status change events to administrator through the snmp trap(alarm).

    Why Need SNMP

    The basic idea of snmp is to define a unified interface and protocol for devices of different types, manufacturers, and models, so that administrators can manage these network management devices with a unified interface, improving the efficiency of network management and simplifying the work of network administrators. snmD is designed on the TCP/P protocol family, works based on TCP/IP protocol, and manages the devices that support snmp protocol in the network 

    Target

    1. we can learn how to configure SNMP on MTG device through the document

    2. we can learn how to set/get data of MTG and MTG trap events to snmp server through the document.

    Description

    In the document, we used SNMP software "MG-SOFT MIB brower" and it is an extremely flexible, technically sophIisticated, powerful and user-friendly SNMP browser,It allows you to monitor and manage any SNMP on your network using the SNMPv1, SNMPv2c and SNMPv3 protocols over UDP and TCP over IPv4 and IPv6 networks equipmen.

    The IP of SNMP server is 172.27.0.155

    The IP of test MTG device is  172.19.211.133 (MTG2000, version is 02061125P12)

    2. Configure On MTG 

    2.1. Enable SNMP and choose SNMP version

    MTG support all three version v1/v2c/v3 of snmp,  it is as below

    Please enable SNMP and choose the  version same as SNMP server. we will using the version  V2C in the sample.

    2.2 Configure Community Configuration

    Description:

    This configuration is applicable to v1 and v2c. You need to configure the community and source address. Community is a string equivalent to a password in authentication; The source IP address is the IP address of the snmp server. The default value is default(means any ip). This configuration is for configure snmp server information. the community must be same with SNMP server .

    In the sample, we configure public as community and default as source. it means we also configure public community on SNMP server.

    2.3 User Configuration

    Description:

    This configuration is applicable to V3 version. You need to set the user name, authentication type, authentication password, encryption type, and encryption password. Add authentication information to SNMP v3 messages and encrypt the packet content. those information is provided by SNMP server.

    In the sample , we do not use V3 version, so keep this the user configuration to blank.

    2.4 Group Configuration

    Description:

    This configuration is applicable to v1/v2c/v3 version. The group name is a string and we can  set any string as group name. then select the community that has been configured.  The community is added to a group. The access configuration of step 5 configure  give access authority of red/write/trap based on the group name.

    2.5 View Configuration

    Description:

    This configuration is applicable to v1/v2c/v3 version. The ViewName is a string and we can  set any string as View Name. and you need to configure ViewType/ViewSubtree/ViewMask.

    ViewType: it have included and excluded. included means included that MIB node that we set on viewsubtree and excluded means excluded that MIB node that we set on viewsubtree.

    ViewSubtree: MIB node 

    ViewMask:it is mask for MIB OID

    2.6 Access Configuration

    Description:

    This configuration is applicable to v1/v2c/v3 version.you need to select group and select the view for the group to read, write, and notify (trap).

    the view of read/write/notify means give authority of read,write and trap 

    2.7 Configure Trap Configuration

    Description:

    This configuration is applicable to v1/v2c/v3 version.

    Trap type: V1/V2C/V3. it is snmp version that snmp server side used

    Trap ip:  it is ip of snmp server. 

    Trap port: it is snmp port of snmp server. 162 is detaul trap port of snmp procotol.

    Trap community : it is community that SNMP server side used

    In the sample, the ip of snmp server is 172.27.0.155 and trap type of snmp server is v2c. the trap port of snmp server is 162 and trap community of snmp server is public.

    3. Configure On SNMP Server

    3.1. Upload MIB File Of MTG 

    We need to upload MIB file of MTG to the SNMP server. If not, the SNMP server can't recongize the datastruct of MTG, different product using differet MIB file. 

    Note: There is mib file of MTG.

    VOIP-IAD-SIP(2).mib

    When upload successfully, the mib brower will show mib tree of MTG

    3.2 Configure Snmp Server

    We need configure ip of MTG and read community and set community and SNMP port . We also select SNMP version .

    In the sample, the IP of MTG is 172.19.211.133 and used SNMP version V2C. the community of read/set both are public.

    3.3 Contact MTG On SNMP Server

    Right click and it will show menu. then click contact and the SNMP server will connect MTG.

    4. Apply the  SNMP function.

    4.1 Read(Get) Information From MTG

    Right click the node and it will show menu. Then click "Get" and it will get the information from MTG.

    For example, we do it in node "DeviceModel", it  will get the device model

    Get  device model successfully

    4.2 Write(Set) Configuration To MTG

    Right click the node and it will show menu. Then click "Set" in menu. It will Write(Set) the informatin to MTG side.

    For example, we do it in node "MTGSIPServerAddresss", it  will Write(Set) the IP to  MTG. 

    We set the sip port 5070 as local sip port of MTG.



     Settting successfully! the MTG side show local sip port 

    4.3 Trap Information 

    Trap mean the MTG report the status automatic. 

    Check trap message 

    please note: sometimes the trap port will be occupied and we can change the default port 162 to other idle ports. it is as below

    when we changed the trap port on snmp server side and we also need to change the trap port on MTG device.



    When device stauts changed, MTG will send trap message to SNMP server.

  • QHow to Check Calls of MTG Device

    A

    Overview

    This document is intended to introduce how to solve the calling problem of MTG device.

    After finish configurations on the MTG, but calls cannot pass, in this case, you can check flows described on this document.

    All outgoing calls in this document refer to IP->PSTN calls, while incoming call refer to PSTN->IP calls.

    Steps 

    Outgoing call

    The process for checking failed outgoing calls,

    Failed Calls

     When we make an IP to PSTN call but the call fails, we can capture network packages to check whether the call reach the device or not.

    Choose the right network port, which you can check on the System Information pag 

    1. Check Whether Call Reaches Device or Not

    When get the captured network package, check the sip information. If the MTG device receives the “INVITE” session, it means the device has received the call.

    If the device doesn’t receive the “INVITE” session from the sip server, please check the sip server and network setting.

    2. Call Has Reached MTG Device But Still Fail

    If the call reaches the MTG device, but it still fails, you need to track the call log and send it to Dinstar Support to check the reason.

    The processing flow for outgoing call is IP->CC->E1. The MTG device receives the call and the send it to the CC control module for processing of services such as number manipulation and route choosing.

    3. Get and Check the CC processing

    Do PRI trace command

    When you get the log, you can check the cc print first, confirm call send out or not.

    The following is a successful call, also shows how our equipment is handled

    // Receive the call and send it to the CC control module for processing

    [086-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> predispose start calling :15025844 called:24311735!

    [087-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> predispose end calling :15025844 called:24311735!

    [088-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> source user auth:0x6, is fxo call in auth pass:0

    [089-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> route type:3(Out route) -- before cc number analysis.

    [090-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> [IP2tel]match route succ! Index:255(100.160)

    [091-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> DestTermType:pri, There is avaivalble ts!

    [092-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> [before manipulate number]calling:15025844, called:24311735, longNum:15025844, anl called:24311735, isRouteAfNumManip:0, callerNumTyp:255, calledNumTyp:255, presentId:0.

    [093-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> [after manipulate number]calling:15025844, called:24311735, longNum:15025844, anl called:24311735, callerNumTyp:255, calledNumTyp:255, presentId:0.

    [094-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> analysis successfully, service:0(normal), bill:4(normal), route:3(rts_out), dest_term:5(Pra), dest_dev:65535, dest_port:65535, dest_grp:65535, called:24311735 !

    [095-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> number convert, old calling:15025844, old called:24311735

    [096-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> before trans num process! caller:15025844, disNum:, called:24311735, g_ulIsTransOrgCalleeNum:0, g_ulNumTransType:0, g_ulAllowMobileTransfer:0!

    [097-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> number convert, new calling:15025844, dis num:, new called:24311735

    [098-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> ==>> CC_ST_PROCEEDING, called:24311735

    [099-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> calling :0.0.0.0  called:255.255.255.255

    [100-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> is need reflect:0, callingProfId:0.

    [101-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> ==>> CC_ST_SETUP, cr:12, calling:15025844, longNum:15025844, dial:24311735, OrgCallee:, InvokeArgs:, num_ok:1, trunkGrpId:128, profileId:255, isForceReflect(ccb):0, ringback2IP:1, PoolId:255std sdp:v=0

    o=sip-02.05.04.02 474751 474752 IN IP4 172.30.222.18

    s=-

    c=IN IP4 172.30.222.18

    t=0 0

    m=audio 6144 RTP/AVP 18 0 18 4 101

    a=rtpmap:18 G729/8000

    a=fmtp:18 annexb=no

    a=rtpmap:0 PCMU/8000

    a=rtpmap:18 G729/8000

    a=fmtp:18 annexb=no

    a=rtpmap:4 G72

    [102-17:29:59:560]CC: <6,Sip-t,0,65535,,idle> ccb state change from 'idle' to 'proceeding', ccb no:6

    [103-17:29:59:560]CC: <Sip-t,0,65535>, <Pra,65535,65535>, ====Processed: CC_ST_SETUP

    [104-17:29:59:560]CCB: no:6, cr1:11, cr2:12, State:4(proceeding), SubState:0(idle), serv:0(normal), serv_state:20(), route:3(rts_out), cause:0(CCS_NONE(Ξ???)) 

    [105-17:29:59:560]ST: <6,Sip-t,0,65535,15025844,init> <<== CC_ST_PROCEEDING, Std Sdp:, Priv Sdp:

    [106-17:29:59:560]ST: <Sip-t,0,65535,15025844> ====Processed: CC_ST_PROCEEDING             // The device is ready to be sent to pstn and is being processed

    [107-17:29:59:560]ST: cr, no:11, ccb:6, State:4(out_proc), cause:0(CCS_NONE(Ξ???)), redirect:0 

    [108-17:29:59:560]ST: <6,,65535,65535,,idle> <<== CC_ST_SETUP, calling:15025844, long:15025844, dial:24311735, send_ok:1, p:0, poolId:255, Std Sdp:v=0

    o=sip-02.05.04.02 474751 474752 IN IP4 172.30.222.18

    s=-

    c=IN IP4 172.30.222.18

    t=0 0

    m=audio 6144 RTP/AVP 18 0 18 4 101

    a=rtpmap:18 G729/8000

    a=fmtp:18 annexb=no

    a=rtpmap:0 PCMU/8000

    a=rtpmap:18 G729/8000

    a=fmtp:18 annexb=no

    a=rtpmap:4 G723/8000

    a=fmtp:4 annexa=no

    a=rtpmap:101 telephone-event/8000

    a=fmtp:101 0-15

    a=ptime:20

    , Pri

    [109-17:29:59:560]ST: <6,Pra,65535,65535,,idle> ==>> CC_SETUP_REQ, index:12, if:65535, trunkGrp:128, calling:15025844, called:24311735, callingTyp:255, calledTye:255, presentId:0, trans:   //Call information to pri or ss7 module

    [110-17:29:59:560]ST: <Pra,65535,65535,> ====Processed: CC_ST_SETUP

    [111-17:29:59:560]ST: cr, no:12, ccb:6, State:6(present), cause:0(CCS_NONE(Ξ???)), redirect:0 

    [112-17:29:59:560]ST: <Pra,65535,65535,> ====Processed: CC_ST_SETUP

    [113-17:29:59:560]ST: cr, no:12, ccb:6, State:6(present), cause:0(CCS_NONE(Ξ???)), redirect:0 

    [114-17:29:59:560]Q931<-CC, CC_SETUP_REQ:uif=65535,trunkgrp=128,profile=255,cid=0xffffffff,uid=0xc,cause=0

    [115-17:29:59:560]callerNum=15025844 calleeNum=24311735 is_send_end=1

    [117-17:29:59:560]Q931->LCM, MT_SETUP:com=128,cr=0x8006     // pri to pstn

    Which protocol your E1 line using can use the right command to track the log .

    4. Track the Processing on PRI Side

    If call is send out to PRI side, then we can check the processing on the PRI side.

    Analysis Skills for MTG PRI Message

    Message direction: Q931 can be understood as the upper layer, LCM can be understood as the bottom layer (link layer) , So it means sending out; 

    Q931-> LCM means MTG sends messages to the peer end of the PRI.

    Q931 <-LCM means receiving the message sent from the E1 side, the peer is the PRI.

    Message type: XXX in MT_XXX represents the message name

    Message content: IE_XXX is the name of the IE field carried in the message, followed by hexadecimal content, the specific meaning needs to be compared with Q.931 protocol; however, the calling and called numbers can be read directly because the number is encoded with ASCII , There are rules to follow, such as the following calling IE.

    IE_CALLING_PN 6c 0b 01 80 33 34 37 38 38

    The number is composed of the string of 3X, remove the 3 of each 3X, and the rest is the number information, "33 34 37 38 38" corresponds to the number "34788".

    Call identification: How to find out the information of the same call from the mixed messages, we can use the CR value.

    "Q931-> LCM, MT_SETUP: com = 0, cr = 0x8009" There is a field of cr = xxx after each message. Messages with the same cr value belong to the same call of the trunk.

    l Below is a sample of MTG PRI messages, you can compare with your log.

    //Receive cc call request, send MT_SETUP message to peer

    24 23:46:19.290 mpe_q931: <133>  [   INFO] Q931<-CC, CC_SETUP_REQ:uif=65535,trunkgrp=0, profile=255, cid=0xffffffff,uid=0x24,cause=0

    24 23:46:19.290 mpe_q931: <134>  [   INFO] callerNum=347883441 calleeNum=111445678 is_send_end=1

    24 23:46:19.290 mpe_q931: <135>  [   INFO] Q931->LCM, MT_SETUP:com=0,cr=0x8009

    24 23:46:19.290 mpe_q931: <136>  [   INFO]  IE_BEARER 04 03 80 90 a3

    24 23:46:19.290 mpe_q931: <137>  [   INFO]  IE_CHANNEL_ID 18 03 a9 83 89

    24 23:46:19.290 mpe_q931: <138>  [   INFO]  IE_CALLING_PN 6c 0b 01 80 33 34 37 38 38 33 34 34 31

    24 23:46:19.290 mpe_q931: <139>  [   INFO]  IE_CALLED_PN 70 0a 81 31 31 31 34 34 35 36 37 38

    24 23:46:19.290 mpe_q931: <140>  [   INFO]  IE_COMPLETE a1

    24 23:46:19.290 mpe_q931: <141>  [   INFO] Q931->CC, CC_PROCEEDING_IND:uif=0,trunkgrp=0,profile=0, cid=0xab7,uid=0x24,cause=0

    //During the caller's connection phase, receive MT_CALL_PROCEEDING from callee

    24 23:46:19.350 mpe_q931: <154>  [   INFO] Q931<-LCM, MT_CALL_PROCEEDING:com=0,cr=0x8009

    24 23:46:19.350 mpe_q931: <155>  [   INFO]  IE_CHANNEL_ID 18 03 a9 83 89

    24 23:46:19.350 mpe_q931: <156>  [   INFO]  IE_PROGRESS 1e 02 81 81

    24 23:46:19.350 mpe_q931: <157>  [   INFO] Q931->CC, CC_PROCEEDING_IND:uif=0,trunkgrp=0,profile=0, cid=0xab7,uid=0x24,cause=0 chn=(0,9)

    // In the ringing phase,  receive MT_ALERTING from callee

    24 23:46:19.390 mpe_q931: <161>  [   INFO] Q931<-LCM, MT_ALERTING:com=0,cr=0x8009

    24 23:46:19.390 mpe_q931: <162>  [   INFO]  IE_PROGRESS 1e 02 81 88

    24 23:46:19.390 mpe_q931: <163>  [   INFO] Q931->CC, CC_ALERTING_IND:uif=0,trunkgrp=0,profile=0, cid=0xab7,uid=0x24,cause=0

    // During the caller connection phase, receive MT_CONNECT from callee

    24 23:46:31.350 mpe_q931: <167>  [   INFO] Q931<-LCM, MT_CONNECT:com=0,cr=0x8009

    24 23:46:31.350 mpe_q931: <168>  [   INFO] Q931->CC, CC_SETUP_CFM:uif=0,trunkgrp=0,profile=0, cid=0xab7,uid=0x24,cause=0

    24 23:46:31.350 mpe_q931: <169>  [   INFO] Q931->LCM, MT_CONNECT_ACKNOWLEDGE:com=0,cr=0x8009

    // In the disconnection phase, the called party disconnects and receives the MT_DISCONNECT from callee

    24 23:46:39.230 mpe_q931: <175>  [   INFO] Q931<-LCM, MT_DISCONNECT:com=0,cr=0x8009

    24 23:46:39.230 mpe_q931: <176>  [   INFO]  IE_CAUSE 08 02 80 90

    24 23:46:39.230 mpe_q931: <177>  [   INFO] Q931->CC, CC_DISCONNECT_IND:uif=0,trunkgrp=0,profile=0, cid=0xab7,uid=0x24,cause=144

    24 23:46:39.230 mpe_q931: <178>  [   INFO] cause string=Normal call clearing

    24 23:46:39.230 mpe_q931: <179>  [   INFO] Q931<-CC, CC_RELEASE_REQ:uif=0,trunkgrp=0,profile=0, cid=0xab7,uid=0x24,cause=144

    24 23:46:39.230 mpe_q931: <180>  [   INFO] cause string=Normal call clearing

    24 23:46:39.230 mpe_q931: <181>  [   INFO] Q931->LCM, MT_RELEASE:com=0,cr=0x8009

    24 23:46:39.270 mpe_q931: <185>  [   INFO] Q931<-LCM, MT_RELEASE_COMPLETE:com=0,cr=0x8009

    24 23:46:39.270 mpe_q931: <186>  [   INFO] Q931->CC, CC_RELEASE_CFM:uif=0,trunkgrp=0,profile=0, cid=0xab7,uid=0x24,cause=0

    l Track the SS7 call

    linkId   hdlcNo   mode    revErrs   cc       rc        lsc        iac        poc       txc       aerm    suerm daedt daedr qlen    ST     UseCnt 

    0          16           main      Default   0       free     open   open     free      free       open    free    open   open          open      0

    1          18          backup   Default   0       free     open   open     free      free       open    free    open   open          open      0

    online total links: 2

    How to save the log

    You can use application “putty” to save the log real time as follow

    Incoming Calls

    Incoming calls is different with outgoing calls, the flow for checking is just the opposite.

    Flow for checking incoming calls is PSTN>>CC>>IP.

    1. Track the Processing on the PRI Side 

    Check whether the incoming call reaches the MTG device or not. We need to track the PRI or SS7 logs, and then check whether the device receives the call from PSTN side or not.

    If the call reaches the MTG device, we check the CC processing.

    You can do the same as 2.31 or 2.33, track the call and check the processing on PSTN (PRI) side.

    2. Check CC Processing

    If the call reaches the MTG device but still fails, we can check CC to see whether the call gets the right route and has right number manipulation or is sent to the IP side.

    3. Network Capturing

    Capture network packages to see whether the sip call responds or not and confirm the caller, callee, server IP and server port.

    4. Contact Dinstar Support

    If the call still fails and the checking flow in this document can’t help you solve the call problem, please send the telnet log and captured network packages to Dinstar Support.

  • QSS7 master-slave

    A

    Index: Centralized model and Distributed model ,master and salve device shared signaling time slot.

    the difference is ip trunk send call to which:

     sip server only send call to master device by Centralized model,so slave device don’t need set anything

    sip server send call to master and salve devices by Distributed model,so we need set same configuration in salve device.

    Next, configuration examples,master device is 4 ports,salve device is 8 ports

    1. Centralized Model

    1.1 Master device configuration

    1. 

    a. Local TG Flag choose Master centralized

    b.CIC

    2. Salve device confighuration

    a. Local TG Flag choose Slave centralized

    b.Needn’t config others

    2. Distributed model

    1.master device configuration

    a. Local TG Flag choose Master Distributed 

    2. Salve device confighuration

    a. Local TG Flag choose Slave Distributed

    b.the date of salve devices and the master device must be same, when configuring ss7 link, select the same E1 port number you added in master device 







    c.CIC

    d.Config others same as master device

Service Feedback
Service Feedback
Please fill in the information and submit the service
evaluation and suggestions online
  • *Name

  • *Country

  • *Company Name

  • *Email

  • *DeviceType

  • *DeviceSN

  • *Snapshot of Device SystemInformation Page