[Freeswitch-users] Problems with Hold, Dynamic Payload, Media Direction
Fuad Trle
trle.fuad at gmail.com
Fri Dec 10 08:50:06 UTC 2021
Hello,
I have encountered several problems while configuring and testing
FreeSWITCH. This is on a current master branch, but the same issues are
present in older versions. The tests are done on a minimal config with
these additions:
vars:
- remove auth
- global_codec_prefs=OPUS,PCMU,PCMA,VP8
- rtp_pass_codecs_on_stream_change=true # To be able to toggle video stream
profiles:
- inbound-late-negotiation (with and w/o inherit codec)
dialplan:
- Simple dial plan. External to Internal flow. Condition for ext, then
bridge call to the other side.
Unfortunately, this Sofia options are removed from FS :( Are there
alternatives for them (while using rtp_pass_codecs_on_stream_change)?
renegotiate-codec-on-hold|true,false
renegotiate-codec-on-reinvite|true,false
(a) -- (FS) -- (b)
*1st: Hold* - Break transcoding.
-- INVITE (Opus, PCMA) --> |
| -- INVITE (PCMA) -->
| <---- OK (PCMA) ----
<------ OK (Opus) -------- |
.
.
| <--- ReINVITE (Hold or video on/off)
<---- ReINVITE (PCMA) ---- |
x
I tried with absolute codec string, inbound/outbound codec prefs... it
seems that FS does not keep/honor previous channel state and does not
differentiate stream change from stream parameters change (like media flow).
*2nd: Dynamic Payload *- It will offer Opus to the other side, because both
have it. But FS will renegotiate with new PT number on reinvite. This break
stream for some endpoints.
-- INVITE (Opus, 111) --> |
| -- INVITE (Opus, 102) -->
| <---- OK (Opus, 102) ----
<---- OK (Opus, 111) ---- |
.
.
| <-- ReINVITE (Hold or new m=line)
<- ReINVITE (Opus, 102) - |
x
Is there a way to originate call with a codec that has a dynamic payload
number, but to choose PT number? Something like setting rfc2833-pt variable
for outbound channel before originating call?
*3rd Media direction* - FS does not propagate media direction parameter to
inbound channel/leg. Inbound side expect media and some endpoints will drop
call after awhile. I know that answering with recvonly does not have sense
for audio, but for a video it has.
-- INVITE (sendrecv) --> |
| -- INVITE (sendrecv) -->
| <---- OK (recvonly) ----
<---- OK (sendrecv) ---- |
For late negotiation this is wrong. Even for early it should be possible to
pass reinvite to the other side on media direction change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20211210/f02fd55a/attachment.html>
More information about the FreeSWITCH-users
mailing list