[Freeswitch-users] Problems with Hold, Dynamic Payload, Media Direction

[Dragos Oancea]

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 at gmail.com> wrote:

> 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.
> _________________________________________________________________________
>
> The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
> Enhance your FreeSWITCH install with disruptive priced SMS and PSTN
> services.
> Build your next product on our scalable cloud platform.
>
> Join our online community to chat in real time
> https://signalwire.community
>
> Professional FreeSWITCH Services
> sales at freeswitch.com
> https://freeswitch.com
>
> Official FreeSWITCH Sites
> https://freeswitch.com/oss
> https://freeswitch.org/confluence
> https://cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> https://freeswitch.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20211222/9773d96f/attachment.html>