[Freeswitch-users] zRTP + OPUS one-way audio issue

Andrea Mazzeo admin at smallunix.net
Wed Jan 30 19:19:58 UTC 2019


Hi,

Is there any hack to suggest me to change payload 102 to 103 inside SDP
before to send to LEG-B?

I would like to send
m=audio 21820 RTP/SAVP 103 101 13
a=rtpmap:103 opus/48000/2
a=fmtp:103 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000;
ptime=20; minptime=10; maxptime=40; stereo=1

instead of
m=audio 21820 RTP/SAVP 102 101 13
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000;
ptime=20; minptime=10; maxptime=40; stereo=1

I'm trying to use regex with switch_r_sdp before bridge, but I'm not
lucky...

Thank you,
Andrea

Il giorno mar 2 ott 2018 alle ore 11:09 Andrea Mazzeo <admin at smallunix.net>
ha scritto:

> Dear All,
>
> I opened a bug for this:
> https://freeswitch.org/jira/browse/FS-11402
>
> I would like to offer a bounty, but it's not easy for me to evaluate the
> amount of needed work.
>
> Please if someone is interested let me know or better share a bid.
>
> Thank you,
> Andrea
>
> Il giorno ven 21 set 2018 alle ore 12:47 Andrea Mazzeo <
> admin at smallunix.net> ha scritto:
>
>> Hi,
>>
>> I'm facing an one-way audio issue with zRTP while using OPUS. zRTP is set
>> in passthru mode.
>> Called party can hear Calling party but not vice versa.
>>
>> Full log:
>> https://pastebin.freeswitch.org/view/639adfe9
>>
>> This issue is happening *only* with dynamic payloads codecs.
>> Everything is working fine if I use G722 or G729.
>>
>> Scenario Leg-A (207) -> FS -> Leg-B (213)
>>
>> Checking FS logs, I see
>>
>> Leg-A's SDP:
>> a=rtpmap:103 opus/48000/2
>>
>> Leg-B's SDP:
>> a=rtpmap:102 opus/48000/2
>>
>> Actually having different payloads should not be an issue.
>> I opened a case to Acrobits, they said the issue is in the actual RTP
>> traffic sent to Leg-A from FS:
>>
>> From the client log Leg-A
>> Sending RTP packet #200 192.168.128.158:59176 > 31.102.111.134:28560,
>> len=116, really=116,
>> data=80679E55DF67E34A291167D899830CC03C124F353DA3C069574410EC0333125F
>> This is using 103, correct as agreed on this side of the call
>>
>> Received RTP packet #200 31.102.111.134:28560 > 192.168.128.158:59176,
>> len=90,
>> data=80663D3B22CC8CB414490864A230F49B6EFF42E7BCA9EB64B864374B1377965C
>> This is using 102, which is wrong for this side of the call.
>>
>> Seems that after negotiated payload 102 with Leg-B, FS is trying to use
>> it on Leg-A, where it should be used 102 instead.
>>
>> Any idea?
>>
>> FreeSWITCH Version 1.8.1-2-4f54cff~64bit (-2-4f54cff 64bit)
>> OS.: Debian 8.11
>> Linux pbx-186 3.16.0-4-amd64 #1 SMP Debian 3.16.51-3 (2017-12-13) x86_64
>> GNU/Linux
>>
>> Thank you,
>> Andrea Mazzeo
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20190130/3e07ce64/attachment-0001.html>


More information about the FreeSWITCH-users mailing list