[Freeswitch-users] Receiving audio despite SDP with a=sendonly

[Larry Hemenway]

I'm back to taking a look at this and have a (perhaps) naive view on
how it could be done. I think I could do something like this:

- In the dial plan set a channel variable that indicates the channel
is one-way-audio capable.
- In switch_core_session_write_frame, there would be a conditional
something like this:
        if ((variable_audio_media_flow == recvonly) && (the
one-way-audio-capable variable == true))
           ... do nothing
        else
           ... do work ...
        endif

In this way legacy behavior is preserved, but there is a way to
accommodate one-way audio. With a clever dial plan you could allow it
for some legs and not others.

If anyone has any thoughts on side effects this might have, let me
know. I plan on prototyping it this week if I can find the time.

Larry




On Fri, Feb 23, 2018 at 8:48 AM, Larry Hemenway
<larry.hemenway at gmail.com> wrote:
> It looks like FreeSWITCH does not support one-way audio at all. We have a
> strong need for this functionality if we choose to use FreeSWITCH. If I were
> to investigate and implement this, is it something that the community would
> be interested in? I'm a bit worried about diving into this because if
> FreeSWITCH honors the sdp direction it could potentially break some legacy
> applications that rely on current functionality.
>
> Also, any tips on where to start would be appreciated.
>
> More info on my investigation:
>
> I got a little smarter in how I search the mailing list and came across
> this, so it sounds like this is not supported functionality.
>
> http://freeswitch-users.2379917.n2.nabble.com/sendonly-attribute-ignored-td5933886.html
>
> I also ran some more experiments. The reinvite with a=sendonly results in a
> hold event, so I verified audio is not passed in either direction despite
> the SDP direction attribute.
>
> I'm currently doing these experiments with a conference. We would like to
> use it as a sort of intercom function, but our security group is strongly
> discouraging us from making a product that sends audio to all the endpoints
> even if its silence, so the conference relate API, from their perspective,
> isn't a solution.
>
> Larry
>
>
>
> On Wed, Feb 21, 2018 at 5:09 PM, Larry Hemenway <larry.hemenway at gmail.com>
> wrote:
>>
>> Hello,
>>
>> Is there a way to establish a call with one-way audio on a call from the
>> start?
>>
>> I'm currently sending a request with the following SDP - (note
>> a=sendonly):
>>
>> v=0
>> o=Larry 2890844526 2890844526 IN IP4 127.0.0.1
>> s= My Session
>> c=IN IP4 172.22.112.1
>> t=0 0
>> m=audio 49170 RTP/AVP 0 8
>> a=sendonly
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>>
>> FreeSWITCH is sending back the right response (note the a=recvonly):
>>
>> v=0
>> o=FreeSWITCH 1519171720 1519171721 IN IP4 172.17.0.2
>> s=FreeSWITCH
>> c=IN IP4 172.17.0.2
>> t=0 0
>> m=audio 21768 RTP/AVP 0 101
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-16
>> a=recvonly
>> a=ptime:20
>>
>> But I'm still receiving audio from FreeSWITCH. It is only after I
>> resend the SDP via a reinvite that the audio stops being sent from
>> FreeSWITCH.
>>
>> Larry
>
>