native bridge mode
- This is supposed to be included in commit of
b324f86797. Somehow it's
not included in that commit. Without this change, the
REL receiving leg always stay in TERMINATING state when
received an incoming REL message.
is down and recovered later
To re-produce this bug:
1. do CGB on one side
2. unplug signaling link cable
3. plug signaling link cable back
4. do CGU on the blocking side
5. cic state stay in RESTART for ever
Fix this problem by sending cic to SUSPENDED state after
receiving/sending CGU message
- When NSG receives INR from network, send back INF with calling
party category information IE and calling number information IE.
- Introduced a new global setting of "force-inr" for testing
purpose. Stinga generated INR/INF packets are not acceptable by
trillium stack since it misses call related information in the
packets. If configure force-inr to true in freetdm.conf.xml, when
NSG receives an incoming IAM, it'll send out INR packet regardless
of incoming IAM's IEs, and keep waiting for INF response from the
calling side.
- T.39 timer is introduced in order to handle INR timeout. The
default value of T.39 is 12 seconds and is configurable according
to spec.
- Only supports calling number IE and calling party category IE in
current fix. The customer only needs the calling number IE right now.
In ISUP spec, there are 6 optional IEs. NSG only supports calling
party number and calling category information IE since the other
IEs are not configurable in freetdm.conf.xml or included in IAM
message.
- In collect state, INR/INF implementation needs to work with existed
SAM messages. If NSG sent out INR and wait for SAM, collect state
check both INF received and enough dialed numbers received. If one
of these conditions are not met, it'll stay in collect state and wait
until either conditions met or timeout. After received INF and enough
dailed number, state moves to dailing and proceed as regular calls.
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
This fixes an issue where ss7 native bridge was accidentally enabled
any time two freetdm channels were bridged regardless of the freetdm_native_sigbridge
variable value.
Use the amount of audio data received in misdn_read() to determine how many
bytes we need to send to the b-channel (= how much free space is left
in the b-channel tx queue). (This is how libosmo-abis and LCR handle it too.)
A pipe is used as a poll()-able audio tx buffer (filled in misdn_write()):
FTDM_WRITE wait requests are currently poll()-ed on the input side of the pipe,
whereas FTDM_READ and _EVENT requests are poll()-ed on the b-channel socket itself.
For every N-bytes of audio data read from the b-channel in misdn_read(),
we try to get as much out of the tx pipe, convert it into the ISDN_P_B_RAW
format and send it to the b-channel socket.
If there's less than N-bytes left in the pipe, we fill the remaining buffer
with silence to avoid buffer underflows.
B-Channel handling overview:
- misdn_wait(FTDM_WRITE) on audio pipe
- misdn_write() put audio data into pipe
- misdn_wait(FTDM_READ) for next incoming mISDN
message on b-channel socket
- misdn_read() handle mISDN event, for PH_DATA_IND:
- Write data into channel buffer and convert
to a/u-law using misdn_convert_audio_bits()
- Try to fetch N-bytes from audio pipe
- If not enough bytes in pipe: fill remaining space with silence
- Convert audio to raw format
- Send to b-channel (PH_DATA_REQ)
Known problems / bugs / further investigation:
1. Bridge aborted by "Write Buffer 0 bytes Failed!" error from switch_core_io.c.
This is "fixed" by _not_ setting the b-channel sockfd to non-blocking mode.
2. Audio glitches (maybe caused by FTDM_WRITE misdn_wait() handling or blocking I/O on sockfd?)
3. misdn_read() EBUSY error messages from sending data to b-channel sockfd after enabling channel.
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
The former fixes a strange "bug" with hfcsusb, where a b-channel deactivation
on a inactive channel (caused by a reset cycle) would cause the port to
lock up and stop processing events.
NOTE: this still needs to be investigated further, but this workaround will
at least prevent it from breaking completely.
We'll now keep track of the channel activation state and not send any
PH_ACTIVATE_REQ / PH_DEACTIVATE_REQ requests, if the channel already has the
desired state.
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
kapil
David Yat Sin
James Zhang
Anthony Minessale
Stefan Knoblich