VoIP Mailing List Archives

[trle.fuad at gmail.com]

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.

[dragos at freeswitch.org]

Recent commit 6c87ed491597fb5e30935d8309aa7e0c3aa9e18f to master branch should fix at least the 1st and the 2nd described issues. 



On Fri, Dec 10, 2021 at 3:46 PM Fuad Trle <trle.fuad@gmail.com (trle.fuad@gmail.com)> wrote: