- 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.

This reverts commit e560ddcc.

This reverts commit f1d80cd2.

            we dont want to optimize out symbols for debugging

         - glare
         - cgb/cgu range bug
         - inhibit/uninhibit

         The code was improperly using peer_data as an indicator that the sigbridge
         ss7 mode was enabled. The channel flag FTDM_CHANNEL_NATIVE_SIGBRDIGE should
         be used instead

freetdm: Fix improper logging statement when doing native ss7 bridge (peer_chan was set to the SIP leg)

freetdm: Add support to set/receive location and original call number SS7 elements through variables (including SIP X headers)

         - The outgoing tdm leg should not move to UP until
           after the IAM is sent at the end of the function
         - The UP state should be processed immediately otherwise
           the state processor is not run due to the way the main
           ss7 processing loop currently works

         for native bridging that caused infinite SUSPEND state executions
         due to peer member not being cleared at the end of the call

         - The queue size has been bumped again, long calls could potentially require more elements (multiple resume/suspend)
         - The queue is only used when there is a call active

           disable t6 finished.

         - Send RLC immediately even when in native bridge mode
         - Do not enqueue RLC coming from the network

         - Enable native bridge also when receiving the UUID via SIP header
         - Remove some debug CRIT messages and set a more proper log level

         - Fix typo when unlocking channel that resulted in deadlock
         - Defer clearing of the peer data until it is completely safe (next call)

           to give the ability to change RDNIS Presentation value for
           Transparent IAM