In response to a 'secure' offerless SIP Invite, the Janus WebRTC server is missing SDES in the offer SIP 200OK with SDP

Hi,

I am using the Janus WebRTC Server version 1.2.4 for secure SIP calling.

Issue short description: When the Janus WebRTC server receives the offerless SIP Invite from the secure SIP SBC, then the server is expected to create the 200OK response with the offer SDP containing SDES (a=crypto line).
But as observed, the Janus WebRTC server creates the 200OK response without the SDES (a=crypto line) in the offer SDP. This is not liked by the secure SIP SBC and the call ultimately fails.

May I please request help on how to get this issue solved? Or is it a bug in Janus which needs to be fixed??

Detailed description:

  1. The Janus WebRTC server sits between the Browser-based WebRTC client and the secure SIP SBC.
    Browser-based WebRTC client ← DTLS → Janus WebRTC server ← Secure SIP TLS/SRTP → secure SIP SBC.

  2. The WebRTC client sends the Register Request with the parameter: “sips”:true and “outbound_proxy”:“sips:sipSbcFqdn:5060”. Here the outbound_proxy is the secure SIP SBC FQDN.

  3. The secure SIP SBC sends offerless Invite to the Janus WebRTC server:

  4. The WebRTC client accepts the offerless INVITE and generates the JSEP Offer, along with the parameter: srtp":“sdes_mandatory”
    2026-01-16T17:53:04.160911+01:00 serverName janus[3434167]: [Fri Jan 16 17:53:04 2026] [WSS-0x74fa4c016da0] First fragment: 981 bytes, 0 remaining
    2026-01-16T17:53:04.160959+01:00 serverName janus[3434167]: [Fri Jan 16 17:53:04 2026] {“janus”:“message”,“body”:{“request”:“accept”,“autoaccept_reinvites”:false,“srtp”:“sdes_mandatory”},“transaction”:“8I0TsK7FwElp”,“jsep”:{“type”:“offer”,“sdp”:“v=0\r\no=- 7851836171745351593 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0\r\na=msid-semantic: WMS a76e0959-a56e-4026-b5e9-55f76f844ecb\r\nm=audio 9 UDP/TLS/RTP/SAVPF 8\r\na=rtpmap:8 PCMA/8000\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:9S4X\r\na=ice-pwd:BTJE19cQz1usw1DurPNYpOXI\r\na=ice-options:trickle\r\na=fingerprint:sha-256 42:A3:40:86:69:9C:20:81:9B:4A:B5:DA:A4:C2:1F:EF:12:0F:40:C5:1F:43:F7:13:1F:0A:61:7A:91:F9:29:1F\r\na=setup:actpass\r\na=mid:0\r\na=sendrecv\r\na=msid:a76e0959-a56e-4026-b5e9-55f76f844ecb 2287f364-4f63-4663-b8f2-29032084b63c\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=ssrc:1078264070 cname:v1QU0AAva+kHoBGz\r\na=ssrc:1078264070 msid:a76e0959-a56e-4026-b5e9-55f76f844ecb 2287f364-4f63-4663-b8f2-29032084b63c\r\n”},“session_id”:2869723397790328,“handle_id”:3688478866178026}
    2026-01-16T17:53:04.161028+01:00 serverName janus[3434167]: [Fri Jan 16 17:53:04 2026] [WSS-0x74fa4c016da0] Done, parsing message: 981 bytes

  5. The Janus WebRTC server generates the offer 200OK with SDP, but the SDES (a=crypto line) is missing in the SDP. It appears that the Janus WebRTC server forgot about the parameter: srtp":“sdes_mandatory”
    2026-01-16T17:53:04.165105+01:00 serverName janus[3434167]: tport_vsend(0x74fa6c054390): 873 bytes of 873 to tls/sipSbcIpAddress:5060
    2026-01-16T17:53:04.165126+01:00 serverName janus[3434167]: tport_vsend returned 873
    2026-01-16T17:53:04.165192+01:00 serverName janus[3434167]: send 873 bytes to tls/[sipSbcIpAddress]:5060 at 16:53:04.163022:
    2026-01-16T17:53:04.165218+01:00 serverName janus[3434167]: ------------------------------------------------------------------------
    2026-01-16T17:53:04.165237+01:00 serverName janus[3434167]: SIP/2.0 200 OK
    2026-01-16T17:53:04.165282+01:00 serverName janus[3434167]: Via: SIP/2.0/TLS sipSbcIpAddress:5060;branch=z9hG4bKdbu45o3068cv6g6fo250.1;rport=5060
    2026-01-16T17:53:04.165303+01:00 serverName janus[3434167]: From: <sip:my_user_number@users_domain;user=phone>;tag=1514226872-1768582380109-
    2026-01-16T17:53:04.165322+01:00 serverName janus[3434167]: To: <sip:my_user_webrtc@users_domain>;cscf;tag=yU78Q0j87rpjc
    2026-01-16T17:53:04.165342+01:00 serverName janus[3434167]: Call-ID: BW1753001091601261937301579@remoteServerIpAddress
    2026-01-16T17:53:04.165387+01:00 serverName janus[3434167]: CSeq: 601668903 INVITE
    2026-01-16T17:53:04.165407+01:00 serverName janus[3434167]: Contact: 4520309367 my_user <sips:my_user@janusServerPublicIpAddress:33567>
    2026-01-16T17:53:04.165426+01:00 serverName janus[3434167]: User-Agent: Janus WebRTC Server SIP Plugin 0.0.9
    2026-01-16T17:53:04.165444+01:00 serverName janus[3434167]: Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, REFER, MESSAGE, INFO, NOTIFY
    2026-01-16T17:53:04.165462+01:00 serverName janus[3434167]: Supported: replaces
    2026-01-16T17:53:04.165513+01:00 serverName janus[3434167]: Content-Type: application/sdp
    2026-01-16T17:53:04.165538+01:00 serverName janus[3434167]: Content-Disposition: session
    2026-01-16T17:53:04.165564+01:00 serverName janus[3434167]: Content-Length: 240
    2026-01-16T17:53:04.165617+01:00 serverName janus[3434167]:
    2026-01-16T17:53:04.165638+01:00 serverName janus[3434167]: v=0
    2026-01-16T17:53:04.165663+01:00 serverName janus[3434167]: o=- 5659660038060563484 9074819002137646724 IN IP4 janusServerLocalIpAddress
    2026-01-16T17:53:04.165710+01:00 serverName janus[3434167]: s=-
    2026-01-16T17:53:04.165734+01:00 serverName janus[3434167]: t=0 0
    2026-01-16T17:53:04.165752+01:00 serverName janus[3434167]: m=audio 27918 RTP/SAVP 8
    2026-01-16T17:53:04.165780+01:00 serverName janus[3434167]: c=IN IP4 janusServerLocalIpAddress
    2026-01-16T17:53:04.165835+01:00 serverName janus[3434167]: a=rtpmap:8 PCMA/8000
    2026-01-16T17:53:04.165857+01:00 serverName janus[3434167]: a=mid:0
    2026-01-16T17:53:04.165877+01:00 serverName janus[3434167]: a=msid:a76e0959-a56e-4026-b5e9-55f76f844ecb 2287f364-4f63-4663-b8f2-29032084b63c
    2026-01-16T17:53:04.165905+01:00 serverName janus[3434167]: ------------------------------------------------------------------------

  6. The Secure SIP SBC doesnot likes the offer 200OK with SDP, but without the SDES (a=crypto line). The Secure SIP SBC returns the ACK but without SDP. The call ultimately fails.

Thanks.

Whether the 200 OK will include crypto attributes or not is not something the SIP plugin decides, but users. Users will dictate whether SRTP should be negotiated in the messages they send to the plugin to originate/accept calls. Please refer to the documentation for more info.

Edit: ah, apologies, you’re using the “sdes_mandatory” stuff already. I’m pretty sure it’s because you’re using offerless INVITEs, where an “accept” expects to find an SDP to answer to rather than originate one. I’ll check if there’s something broken there, but if you have ways to make some test with “regular” calls too (original INVITE does have an SDP and does have crypto) that would help.

As a side note, can you also check if 0.x works instead? SDP management changed a bit, there, and so I want to make sure it’s not a generic regression.

I think I found the bug. This PR is an attempt to fix it:

Please test and provide feedback directly on GitHub.