[Freeswitch-users] 183 after 180
Kristian Kielhofner
kris at kriskinc.com
Thu Jun 16 02:06:13 MSD 2011
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
More information about the FreeSWITCH-users
mailing list