[Freeswitch-users] How to call multi gateways for failover with early media?

[Anthony Minessale]

The default in originate is to return as soon as there is media.
So if you bridge an inbound call, FS core will use originate to establish
the outbound leg, as soon as it gets media (18X + sdp) it will return and
enter the bridge in early media, this allows you to hear the early media
while you are waiting for answer.

If you want to wait for answer you add {ignore_early_media=true} to the dial
string which tells originate to wait for answer or hangup before returning.

if you are doing a forked dial and you don't just want the first one that
has media to send a 183, you need to also enable {ignore_early_media=true}
for that call.



On Mon, Apr 6, 2009 at 8:47 AM, David Knell <dave at 3c.co.uk> wrote:

> On Mon, 2009-04-06 at 00:08 -0400, Kristian Kielhofner wrote:
>
> > Actually using 180 w/o SDP provides for enhanced call handing
> > functionality while only requiring (in many cases) one additional test
> > scenario.  Consider the current example (all 180s are actually 180s
> > w/o SDP and 183 is 183 w/ SDP):
> >
> > Bridging a call to multiple destinations (A, B, and C).
> >
> > A: 100,180
> > B: 100,180,200
> > C: 100,183
> >
> >   We could have implemented proper forking if it weren't for C who
> > insisted on sending media early (for whatever reason).  While I could
> > see many scenarios where this might happen even with the configuration
> > I suggest, consider what would happen in the ideal scenario:
> >
> > A: 100,180
> > B: 100,180,200
> > C: 100,180
>
> > Ah, B won because it was the first endpoint to actually /answer/ the
> > call and begin playing media.  Nice and clean.
>
> Hang on - if you want to bridge the call on *answer*, then bridge it on
> answer, not when one leg starts sending you early media.  I've no idea
> if FS supports this behaviour for its forked dialling, but it's easy
> to do with a bunch of originates, and uuid_bridge the inbound leg to the
> first one which answers.
>
> > People poke at SIP all the time for this one but this is where the
> > PSTN even seems a bit ambiguous.  We have ISDN cause codes AND inband
> > audio messages?
>
> Yes.  A clearing code is used when the call's cleared; inband audio
> can be used to give the caller more information than a simple clearing
> code might allow - for example, "The number you are calling has been
> changed.  Please redial on whatever the new number might be."  It
> makes eminent sense - simple, common causes (e.g. user busy) get dealt
> with as part of the call clearing and it's the responsibility of the
> originating switch to tell the user; more (indeed arbitrarily) complex
> ones are dealt with by the far end.
>
> --Dave
>
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090406/6ff22ae1/attachment-0002.html