[Freeswitch-users] 183 after 180

[David Aldworth]

Your comments about different endpoints reacting different is my concern exactly. That said, we came up with a fairly simple solution (below) that, thus far, seems alright. However, not all scenarios have been fully test, such as what happens if we get an early media operator intercept with the 183, what happens if the endpoint rejects the re-invite, etc.

<action application="set" data="bypass_media=false"/>
<action application="set" data="ringback=$${us-ring}"/>
<action application="set" data="bypass_media_after_bridge=true"/>


On Jun 15, 2011, at 4:06 PM, Kristian Kielhofner wrote:

> David,
> 
>  While the solution you've proposed below is the best in terms of
> media handling I'm not sure how well it will work in practice.
> 
>  If you intercept the 180 and provide 183 w/ media the calling
> endpoint will get media (ringback) from the IP address of your FS
> machine (no problem).  However, when the 183/200 w/ media comes from
> the remote end it is going to contain a different IP address and port
> if you (somehow) re-enable bypass_media.  Even if FreeSWITCH could be
> coerced into doing this I'm not sure that all endpoints will react
> well to this change in connection information from your 183 to the
> remote 183/200.  Technically speaking (RFC) there's nothing wrong with
> it but we all know that doesn't mean there won't be issues doing this
> with the various endpoints in the field.
> 
>  You /may/ get stuck anchoring the media for the entire call in these
> cases where your upstream returns a 180.  Other than that I'd be
> interested to see how you get along with this...
> 
> On Wed, Jun 15, 2011 at 12:24 AM, David Aldworth <daldworth at teliax.com> wrote:
>> I am trying to find the best solution to generate ring on 180 but bypass on 183. We are in the middle, customer -> FS -> pstn. We bypass_media=true for all calls. However, sometimes we get a 180 from the PSTN and FS relays that to the customer, but the customer is not generating ring so the calling party hears dead air. So, the solution would be to anchor media and generate ring when we get a 180, but once the 183 or 200 hits, bypass starts. I suppose we could do an expression match on the 180, ignore early media, generate ring, and bypass media after bridge. Just wondering if there was a better alternative solution.
>> _______________________________________________
>> 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
>> 
> 
> 
> 
> -- 
> Kristian Kielhofner
> 
> _______________________________________________
> 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