[Freeswitch-users] handling signalling externally, RTP via freeswitch

Tue Jul 1 22:33:08 MSD 2014

Dear Michael,

The endpoint is an XMPP component handling a bastard Jingle. So the actual client initiates the call over Jingle. That ends up on my component that in turn signals FS about the incoming call. The client is ready to send RTP, waiting for my component to send a Jingle session-accept packet. For that packet I need an UDP port to tell the Jingle client to send its RTP stream to.

And no, mod_dingaling won't do it. :) We have our own dialect of Jingle and integration with some other stuff that makes us want an external component for this particular path.

Kees Jan

On 1 Jul 2014, at 19:24, Michael Jerris <mike at jerris.com> wrote:

> can you tell us a little more about what exactly is the endpoint that will have "no signaling"  it obviously needs some sort of signaling to exchange media information.
> 
> On Jul 1, 2014, at 8:46 AM, Kees Jan Koster <kjkoster at kjkoster.org> wrote:
> 
>> Dear Stanislav,
>> 
>> I was afraid you were going to say that. :-/ I guess that's what I will have to do then.
>> 
>> Kees Jan
>> 
>> 
>> On 1 Jul 2014, at 14:40, Stanislav Sinyagin <ssinyagin at yahoo.com> wrote:
>> 
>>> hmm, then I don't see much other possibilities. Probably it's easier to add the SIP agent functionality to your non-SIP part?
>>> 
>>> If it's a Java application, there are multiple implementations of SIP for java.
>>> 
>>> From: Kees Jan Koster <kjkoster at kjkoster.org>
>>> To: Stanislav Sinyagin <ssinyagin at yahoo.com> 
>>> Cc: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org> 
>>> Sent: Tuesday, July 1, 2014 2:34 PM
>>> Subject: Re: [Freeswitch-users] handling signalling externally, RTP via freeswitch
>>> 
>>> 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 at 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 at java-monitor.com>
>>>> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>; ssinyagin at 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 at kjkoster.org>
>>>>> To: freeswitch-users at 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 at example.com
>>>>> 
>>>>> --
>>>>> Kees Jan
>>>>> 
>>>>> http://java-monitor.com/
>>>>> kjkoster at kjkoster.org
>>>>> +31651838192
>>>>> 
>>>>> The secret of success lies in the stability of the goal. -- Benjamin Disraeli
>>>>> 
>>>>> 
>>>>> _________________________________________________________________________
>>>>> Professional FreeSWITCH Consulting Services:
>>>>> consulting at freeswitch.org
>>>>> http://www.freeswitchsolutions.com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Official FreeSWITCH Sites
>>>>> http://www.freeswitch.org
>>>>> http://wiki.freeswitch.org
>>>>> http://www.cluecon.com
>>>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>>> _________________________________________________________________________
>>>>> Professional FreeSWITCH Consulting Services:
>>>>> consulting at freeswitch.org
>>>>> http://www.freeswitchsolutions.com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Official FreeSWITCH Sites
>>>>> http://www.freeswitch.org
>>>>> http://wiki.freeswitch.org
>>>>> http://www.cluecon.com
>>>>> 
>>>>> 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
>>>> 
>>>> 
>>>> --
>>>> Kees Jan
>>>> 
>>>> kjkoster at 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 at kjkoster.org
>>> +31651838192
>>> 
>>> 
>>> Change is good. Granted, it is good in retrospect, but change is good.
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Kees Jan
>> 
>> http://java-monitor.com/
>> kjkoster at kjkoster.org
>> +31651838192
>> 
>> Change is good. Granted, it is good in retrospect, but change is good.
>> 
>> 
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>> 
>> 
>> 
>> 
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>> 
>> 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
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> 
> 
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
> 
> 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

--
Kees Jan

http://java-monitor.com/
kjkoster at kjkoster.org
+31651838192

Change is good. Granted, it is good in retrospect, but change is good.