• James Zhang's avatar
    freetdm: Clean up SS7 native bridge code to separate the call control, queuing and · b324f867
    James Zhang 提交于
             resource-cleanup responsibilities clearly between the 2 channels involved in the bridge
    
       - Each channel is responsible for clearning its own peer_data and event queue
         at the end of the call (when moving to DOWN state)
    
       - Each channel dequeues messages only from its own queue and enqueues messages
         in the peer's queue, with the only exception being messages received before
         the bridge is stablished (IAM for sure and possible SAM messages) because
         if the bridge is not yet stablished the messages must be queued by the channel
         in its own queue temporarily until the bridge is ready
    
       - When the bridge is ready it is the responsibility of the incoming channel to
         move the messages that stored temporarily in its own queue to the bridged peer queue
    
       - During hangup, each channel is responsible for moving itself to DOWN. The procedure
         however differs slightly depending on the hangup conditions
    
         If the user requests hangup (ie, FreeSWITCH) the request will be noted by setting the
         FTDM_CHANNEL_USER_HANGUP flag but will not be processed yet because call control is
         driven only by the link messages (so no hangup from ESL or command line allowed)
    
         When REL message comes, the channel receiving it must move to TERMINATING state and:
    
               - If the user has not hangup yet (FTDM_CHANNEL_USER_HANGUP flag not set) then
                 notify the user via SIGEVENT_STOP and wait for the user to move to HANGUP
                 state by calling ftdm_channel_call_hangup() before sending RLC
    
               - If the user did hangup already (FTDM_CHANNEL_USER_HANGUP flag is set) then
                 skip user notification and move to HANGUP state directly where the RLC message
                 will be sent
    
       - On HANGUP state the RLC is sent and the channel is moved to DOWN, final state
         The peer channel will forward the REL message and wait for RLC from the network, when
         RLC is received the channel can move straight to DOWN itself because the peer channel
         is completing its own shutdown procedure when it received the REL message
    b324f867
名称
最后提交
最后更新
..
apr 正在载入提交数据...
apr-util 正在载入提交数据...
broadvoice 正在载入提交数据...
curl 正在载入提交数据...
esl 正在载入提交数据...
freetdm 正在载入提交数据...
iksemel 正在载入提交数据...
ilbc 正在载入提交数据...
js 正在载入提交数据...
ldns 正在载入提交数据...
libcodec2 正在载入提交数据...
libdingaling 正在载入提交数据...
libedit 正在载入提交数据...
libg722_1 正在载入提交数据...
libnatpmp 正在载入提交数据...
libsndfile 正在载入提交数据...
libteletone 正在载入提交数据...
miniupnpc 正在载入提交数据...
openzap 正在载入提交数据...
pcre 正在载入提交数据...
portaudio 正在载入提交数据...
silk 正在载入提交数据...
sofia-sip 正在载入提交数据...
spandsp 正在载入提交数据...
speex 正在载入提交数据...
sqlite 正在载入提交数据...
srtp 正在载入提交数据...
stfu 正在载入提交数据...
tiff-3.8.2 正在载入提交数据...
unimrcp 正在载入提交数据...
win32 正在载入提交数据...
xmlrpc-c 正在载入提交数据...
yaml 正在载入提交数据...
.gitignore 正在载入提交数据...