Re: [Freeswitch-users] handling signalling externally, RTP via freeswitch
Kees, do I understand it correctly that you're only sending audio towards the SIP endpoint, so it's not a bidirectional conversation? In this case, you can utilize audio streaming via HTTP, probably it's the easiest way to deliver audio toward FreeSWITCH: session.streamFile("shout://some.server.com/file.mp3", "") https://wiki.freeswitch.org/wiki/Mod_shout ________________________________ From: Kees Jan Koster <kjkoster@java-monitor.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>; ssinyagin@yahoo.com Sent: Tuesday, July 1, 2014 1:27 PM Subject: Re: [Freeswitch-users] handling signalling externally, RTP via freeswitch Dear Stanislav, I was rather hoping to avoid that path. My C is not all that great. :-/ But if I have to... Any endpoints that come close that I might want to look at? Kees Jan
AFAIK the RTP parameters and streaming are handled from the endpoint module: https://wiki.freeswitch.org/wiki/Modules
so, you might end up in writing your own module for what you want.
From: Kees Jan Koster <kjkoster@kjkoster.org> To: freeswitch-users@lists.freeswitch.org Sent: Tuesday, July 1, 2014 9:21 AM Subject: [Freeswitch-users] handling signalling externally, RTP via freeswitch
Dear All,
I need some reading advice/pointers on the following: I want to use FreeSwitch as a bridge from a custom client to SIP. The SIP part is easy and works. The non-SIP part is the challenge.
I have my audio sending client hooked up via mod_event_socket. I really like the way events and ESL work in FreeSwitch, by the way. Good control and easy to code. But I digress. So I have my client hooked up over ESL for signalling and need to know where to send the RTP stream to from the non-SIP client side.
Call flow (A-leg is the custom client, B-leg is sofia-SIP) [1] custom client starts call to SIP side over ESL [1] FreeSwitch handles the signalling with the SIP client SIP client answers the call [2] FreeSwitch sends event which tells the client where the RTP stream should go to custom client starts sending RTP audio FreeSwitch bridges the two legs and people talk either side hangs up and the call is done
The reverse (SIP dialling the custom client) won't happen and does not have to be supported.
My concrete question is how [1] should happen. The custom client should issue an "bgapi originate". The arguments for the SIP side are clear, but what to use for the custom client? What should I fill in for [1], below?
bgapi originate [1] sofia/internal/1002@example.com
-- Kees Jan
http://java-monitor.com/ kjkoster@kjkoster.org +31651838192
The secret of success lies in the stability of the goal. -- Benjamin Disraeli
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Kees Jan kjkoster@java-monitor.com http://java-monitor.com/ +31651838192 The secret of success lies in the stability of the goal. -- Benjamin Disraeli
Dear Stanislav, No, the audio will be bi-directional. Other than the custom signalling it will be a regular voice call. Kees Jan On 1 Jul 2014, at 14:31, Stanislav Sinyagin <ssinyagin@yahoo.com> wrote:
Kees, do I understand it correctly that you're only sending audio towards the SIP endpoint, so it's not a bidirectional conversation?
In this case, you can utilize audio streaming via HTTP, probably it's the easiest way to deliver audio toward FreeSWITCH:
session.streamFile("shout://some.server.com/file.mp3", "") https://wiki.freeswitch.org/wiki/Mod_shout
From: Kees Jan Koster <kjkoster@java-monitor.com> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>; ssinyagin@yahoo.com Sent: Tuesday, July 1, 2014 1:27 PM Subject: Re: [Freeswitch-users] handling signalling externally, RTP via freeswitch
Dear Stanislav,
I was rather hoping to avoid that path. My C is not all that great. :-/ But if I have to...
Any endpoints that come close that I might want to look at?
Kees Jan
AFAIK the RTP parameters and streaming are handled from the endpoint module: https://wiki.freeswitch.org/wiki/Modules
so, you might end up in writing your own module for what you want.
From: Kees Jan Koster <kjkoster@kjkoster.org> To: freeswitch-users@lists.freeswitch.org Sent: Tuesday, July 1, 2014 9:21 AM Subject: [Freeswitch-users] handling signalling externally, RTP via freeswitch
Dear All,
I need some reading advice/pointers on the following: I want to use FreeSwitch as a bridge from a custom client to SIP. The SIP part is easy and works. The non-SIP part is the challenge.
I have my audio sending client hooked up via mod_event_socket. I really like the way events and ESL work in FreeSwitch, by the way. Good control and easy to code. But I digress. So I have my client hooked up over ESL for signalling and need to know where to send the RTP stream to from the non-SIP client side.
Call flow (A-leg is the custom client, B-leg is sofia-SIP) [1] custom client starts call to SIP side over ESL [1] FreeSwitch handles the signalling with the SIP client SIP client answers the call [2] FreeSwitch sends event which tells the client where the RTP stream should go to custom client starts sending RTP audio FreeSwitch bridges the two legs and people talk either side hangs up and the call is done
The reverse (SIP dialling the custom client) won't happen and does not have to be supported.
My concrete question is how [1] should happen. The custom client should issue an "bgapi originate". The arguments for the SIP side are clear, but what to use for the custom client? What should I fill in for [1], below?
bgapi originate [1] sofia/internal/1002@example.com
-- Kees Jan
http://java-monitor.com/ kjkoster@kjkoster.org +31651838192
The secret of success lies in the stability of the goal. -- Benjamin Disraeli
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Kees Jan
kjkoster@java-monitor.com
http://java-monitor.com/ +31651838192
The secret of success lies in the stability of the goal. -- Benjamin Disraeli
-- Kees Jan http://java-monitor.com/ kjkoster@kjkoster.org +31651838192 Change is good. Granted, it is good in retrospect, but change is good.
participants (2)
-
Kees Jan Koster
-
Stanislav Sinyagin