Receiving audio despite SDP with a=sendonly
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
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-td5... 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@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
Without knowing all the details of your use case, my suggestion is to put the callers in a conference room and mute one member until desired. Sent from my NationPCS Galaxy Note 5 On Feb 23, 2018 10:14 AM, "Larry Hemenway" <larry.hemenway@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@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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
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@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-td5...
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@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
participants (2)
-
Don Hawkins
-
Larry Hemenway