In the case of a failover, we initiate a re-invite, so its technically a new rtp stream. We do not do in stream state update, so this works fairly well with applications that don't require state updates (such as bridged calls), not nearly as well when talking to an application like in the middle of an ivr or while recording a voicemail. In the case of an application, it would re-enter that application from the start, unless that application has the capability of storing state (most do not, but the infrastructure to do so is in place). Mike On Aug 18, 2014, at 1:41 PM, Alex Balashov <abalashov@evaristesys.com> wrote:
Hi,
Sorry for the newbie question. Regarding this:
https://wiki.freeswitch.org/wiki/Freeswitch_HA
How does FreeSWITCH pick up and resume RTP stream state in this scenario, vis-a-vis the RTP sequence numbers? Or does it not?
I don't really know how RTP works through the FreeSWITCH core. Based on the fact that this type of failover works, I am guessing that Freeswitch has several modes of RTP relay in a channel bridge:
(1) Where the RTP is regenerated/reoriginated with logically independent SSRC and sequence numbers, which would presumably be used in situations where invasive DSP work, transcoding and/or other heavy media involvement is required of the FreeSWITCH core. I assume this involves marshalling the audio payload onto some sort of generic internal audio frame bus, too.
(2) "Light" mode, analogous to Asterisk's "Packet2Packet" bridging, where the RTP is relayed more or less as-is between the endpoints, without this type of mediation. This would presumably pass through the endpoints' respective RTP stream properties.
Is it reasonable to assume that the call recovery functionality relies on #2, which would imply that the calls cannot be transcoded, use in-band DTMF signalling, etc?
Thanks!
-- Alex
-- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language: