No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


The Caller Cannot Hear The Busy Tone If The Callee Is Engated In VOIP Application

Publication Date:  2012-07-27 Views:  529 Downloads:  0

Issue Description

Topology: Tel1 (10882)+PBX1+ AR2810+ INTERNET+ AR2809+ PBX2+ Tel2(37807). 
After finishing the configuration, Tel1 and Tel2 could call each other; when Tel1 is engaged, Tel2 could hear the busy tone when calling Tel1, but when Tel2 is engaged, Tel1 cannot hear the busy tone instead of timeout packet when calling Tel2.

Alarm Information


Handling Process

1. From the sypmptom of failure, the interaction between Tel1 and Tel2 indicates the configuration for VOIP is normal, so we regard the data configuration normal then. (The prediction proves to be false by later facts, impacting the thinking of troubleshooting) .
2. Analyze the packets from debug voip at AR2810 and AR2809; it is found that AR2809 responds AR2810 with busy tone, but AR2810 does not transmit it to the caller TEL1 transparently, but continues calling to the local PBX1 untill PBX1 replies with timeout packet (refer to the packets in reason analysis). So far, we could make sure the problem occurs at the caller side; that is, the caller initiates a call to the local PBX1 after hearing the busy tone from the callee side; 
3. Come to check the configuration of AR2810, and the following is found in the configuration of pots entity: 
  entity 1103 pots
        match-template 3....
        line 0:15
The truth begins to surface. In case AR2810 fails to match VOIP entity, it turns to match POTS entity according to the backup principle. However, PBX1 has no number beginning with "3", making the call time out; 
4. After deleting the relevant configurations of "entity 1103 pots", initiate another call; if Tel2 is engaged, Tel1 could hear the busy tone normally when calling Tel2. 

Root Cause

It involves the backup functionality of VOIP service of AR router: 
Configuring the VoIP voice entity and POTS voice entity with the same callee number could realize IP route selection by means of PSTN. For the callee number, if the peer voice gateway defined by VoIP voice entity is not reachable (network layer is congested),  it would look for POTS voice entity according to the same callee number to match. However, our routers regard the engaging of callee as the unreachability of gateway. In this case, we find the following configurations in the configuration of AR2810 at Tel1 side: 
 entity 387 voip
        address ip
        match-template 387..
  entity 1103 pots
        match-template 3....
        line 0:15
line0: 15 is the E1V1 interface of AR2810 with the local PBX1 interface, and both run ISDN. From the point of configuration opinion,  either VOIP entity or POTS entity could match Tel2 (38707), enabling the backup functionality for VOIP call by accident. If Tel2 is engaged, Tel1 fails to call Tel2. According to call backup principle, AR2810 turns to match the local POTS entity, returning the call to PBX1; but, the local PBX1 has no the telephone beginning with "3", so PBX1 responds a timeout call message to AR2810 which transmits  it transparently to Tel1 at the caller side; thus, from the point of caller opinion, it receives timeout call packet, not busy tone. Executing debug voip command at AR2810 could make the process visible, as follows: 
1. PBX1 echoes a hangup message to AR2810: 
    RX<-     DL_Data_Ind         DISCONNECT          wCES=1
             CRLength=02         CallRef=0x8d1e      
             Cause=0x08 02 81 d8 
2. AR2810 forwards the hangup message to the caller of Tel1: 
    TX->     DL_Data_Req         DISCONNECT          wCES=1
             CRLength=02         CallRef=0xd688      
             Cause=0x08 02 81 d8 
It proves our conclusion further.