The default in originate is to return as soon as there is media.<br>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.<br>
<br>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.<br><br>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.<br>
<br><br><br><div class="gmail_quote">On Mon, Apr 6, 2009 at 8:47 AM, David Knell <span dir="ltr"><<a href="mailto:dave@3c.co.uk">dave@3c.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Mon, 2009-04-06 at 00:08 -0400, Kristian Kielhofner wrote:<br>
<br>
> Actually using 180 w/o SDP provides for enhanced call handing<br>
> functionality while only requiring (in many cases) one additional test<br>
> scenario. Consider the current example (all 180s are actually 180s<br>
> w/o SDP and 183 is 183 w/ SDP):<br>
><br>
> Bridging a call to multiple destinations (A, B, and C).<br>
><br>
> A: 100,180<br>
> B: 100,180,200<br>
> C: 100,183<br>
><br>
> We could have implemented proper forking if it weren't for C who<br>
> insisted on sending media early (for whatever reason). While I could<br>
> see many scenarios where this might happen even with the configuration<br>
> I suggest, consider what would happen in the ideal scenario:<br>
><br>
> A: 100,180<br>
> B: 100,180,200<br>
> C: 100,180<br>
<br>
> Ah, B won because it was the first endpoint to actually /answer/ the<br>
> call and begin playing media. Nice and clean.<br>
<br>
</div>Hang on - if you want to bridge the call on *answer*, then bridge it on<br>
answer, not when one leg starts sending you early media. I've no idea<br>
if FS supports this behaviour for its forked dialling, but it's easy<br>
to do with a bunch of originates, and uuid_bridge the inbound leg to the<br>
first one which answers.<br>
<div class="im"><br>
> People poke at SIP all the time for this one but this is where the<br>
> PSTN even seems a bit ambiguous. We have ISDN cause codes AND inband<br>
> audio messages?<br>
<br>
</div>Yes. A clearing code is used when the call's cleared; inband audio<br>
can be used to give the caller more information than a simple clearing<br>
code might allow - for example, "The number you are calling has been<br>
changed. Please redial on whatever the new number might be." It<br>
makes eminent sense - simple, common causes (e.g. user busy) get dealt<br>
with as part of the call clearing and it's the responsibility of the<br>
originating switch to tell the user; more (indeed arbitrarily) complex<br>
ones are dealt with by the far end.<br>
<br>
--Dave<br>
<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>