Codec Preference Selection Not Supported in JsSIP

[chandrarishabh]

Description

Currently, JsSIP does not provide a way to set or prioritize specific codecs during the SIP negotiation process. This is a crucial feature for optimizing call quality and adapting to different network conditions. Without the ability to select or prioritize codecs, users have limited control over how media is transmitted, potentially leading to suboptimal call quality or compatibility issues with certain systems.

Expected Behavior

JsSIP should expose a method or option that allows users to:
Set codec preferences (e.g., Opus, G.711, G.729, etc.).
Prioritize codecs by defining an order of preference, which would then be reflected in the SDP offer/answer.

Actual Behavior:

JsSIP currently selects codecs without providing a mechanism to modify the codec order or preference. Users cannot influence which codecs are prioritized during SDP negotiation.

Suggested Enhancement

Add a method (e.g., setCodecPreferences()) that allows developers to define the desired codec order for SIP sessions.
Allow this method to take an array of codec identifiers (such as payload types or names), which would then be used to construct the SDP. Ensure that this functionality works for both audio and video codecs.

Example Usage

const codecPreferences: ['opus/48000/2', 'PCMU/8000', 'PCMA/8000'];

session.answer({
mediaConstraints,
pcConfig,
rtcOfferConstraints: {
 offerToReceiveAudio: true,
 offerToReceiveVideo: false,
codecPreferences
}
})

This would result in the SDP offer being constructed with the specified codecs in the preferred order.

Impact

This enhancement would significantly improve the flexibility and performance of JsSIP in various network conditions and across different SIP systems by allowing developers to fine-tune the media negotiation process.

[chandrarishabh]

Let me know if you guys think this feature aligns with vision of JsSIP as a library, will be happy to raise a pull request for the same.

@ibc @jmillan

[ROBERT-MCDOWELL]

would be nice

[AlijiEmmanuel-dev]

This is a very good suggestion. As an example, Some Safari Mobile versions don't support OPUS out of the box, this sometimes causes one way audio between devices. To better leverage the capacity of SIP proxy servers, this would be vital because it could help eliminate the work that needs to be done by RTP proxy, or Media Servers.

…

On Tue, Sep 10, 2024 at 1:18 PM ROBERT MCDOWELL ***@***.***> wrote: would be nice — Reply to this email directly, view it on GitHub <#866 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI64DEOJJMV4VKZ3MC3WTYTZV3PPVAVCNFSM6AAAAABN6TNFLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBQGU2DEMJUGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[chandrarishabh]

yes, we can handle that as well.
Browser has API for getting all the supported codecs. We can handle that gracefully and only honour those which are actually supported by the client browser.

I will raise a pull request for this.

[suryakantgupta321]

We're trying to initiate a video call from a supported softphone like Linphone, but our client web app—built with JSSIP—does not support video calls. To disable video in our client app, we've set the following RTC constraints:

offerToReceiveAudio: true,  
offerToReceiveVideo: false,  

Ideally, JSSIP should handle codec negotiations automatically and convert the incoming video call into an audio call. However, instead of doing so, JSSIP is rejecting the call with a 488 status code.

@chandrarishabh Since you were planning to submit a PR, are you still working on this?

@ibc @jmillan Is this feature currently on the roadmap, or are there plans to include it in our codec negotiation logic? This is a crucial feature for our implementation.