Offerer refusing answer

[Yang Fei]

Hi,

I'm currently trying to integrate with a 3rd party service. The 3rd party is sending us an SDP offer, and we are sending an answer SDP back, however the offerer is thinking that the answer SDP is invalid. Unfortunately there aren't any more detailed logs about why the answer SDP is invalid. 

Could someone please take a look at my SDPs and point out if anything in the answer is incorrect?

Offer SDP:

v=0
o=- 3891007252 3891007252 IN IP4 0.0.0.0
s=a 2 z
c=IN IP4 0.0.0.0
t=0 0
a=group:BUNDLE audio0 video0
m=audio 1 UDP/TLS/RTP/SAVPF 96 0 8
a=candidate:1 1 UDP 2013266431 54.161.129.203 50939 typ host
a=candidate:3 1 TCP 1010827519 54.161.129.203 55636 typ host tcptype passive
a=candidate:2 1 TCP 1015021823 54.161.129.203 9 typ host tcptype active
a=candidate:2 2 TCP 1015021822 54.161.129.203 9 typ host tcptype active
a=candidate:3 2 TCP 1010827518 54.161.129.203 53210 typ host tcptype passive
a=candidate:1 2 UDP 2013266430 54.161.129.203 52305 typ host
a=setup:actpass
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtpmap:96 opus/48000/2
a=rtcp:9 IN IP4 0.0.0.0
a=rtcp-mux
a=sendrecv
a=mid:audio0
a=ssrc:1837795062 cname:user4058814352@host-b89817b0
a=ice-ufrag:2Edj
a=ice-pwd:WMUDiMXJBQAtErMqZM8c2x
a=fingerprint:sha-256 9F:6F:A0:66:86:97:50:26:AE:79:0C:BA:43:29:57:F1:61:43:24:08:7D:90:B0:DE:87:0E:91:8B:FA:52:60:EE
m=video 1 UDP/TLS/RTP/SAVPF 99
a=candidate:1 1 UDP 2013266431 54.161.129.203 50939 typ host
a=candidate:3 1 TCP 1010827519 54.161.129.203 55636 typ host tcptype passive
a=candidate:2 1 TCP 1015021823 54.161.129.203 9 typ host tcptype active
a=candidate:1 2 UDP 2013266430 54.161.129.203 52305 typ host
a=candidate:3 2 TCP 1010827518 54.161.129.203 53210 typ host tcptype passive
a=candidate:2 2 TCP 1015021822 54.161.129.203 9 typ host tcptype active
b=AS:2500
a=setup:actpass
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtpmap:99 H264/90000
a=rtcp:9 IN IP4 0.0.0.0
a=rtcp-mux
a=sendrecv
a=mid:video0
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 ccm fir
a=ssrc:2914048152 cname:user4058814352@host-b89817b0
a=ice-ufrag:2Edj
a=ice-pwd:WMUDiMXJBQAtErMqZM8c2x
a=fingerprint:sha-256 9F:6F:A0:66:86:97:50:26:AE:79:0C:BA:43:29:57:F1:61:43:24:08:7D:90:B0:DE:87:0E:91:8B:FA:52:60:EE

Answer SDP:

v=0
o=- 1683050958664683 1 IN IP4 ***.***.***.***
s=Mountpoint 749D79DBC445_Live
t=0 0
a=group:BUNDLE video0
a=msid-semantic: WMS janus
a=ice-lite
m=audio 0 UDP/TLS/RTP/SAVPF 0
c=IN IP4 ***.***.***.***
a=inactive
a=mid:audio0
m=video 9 UDP/TLS/RTP/SAVPF 99
c=IN IP4 ***.***.***.***
a=sendrecv
a=mid:video0
a=rtcp-mux
a=ice-ufrag:NNc+
a=ice-pwd:mYvWNixOlPmcvnEcjtx+8H
a=ice-options:trickle
a=fingerprint:sha-256 78:38:E0:F1:E7:01:3C:17:D6:91:9D:10:B1:9C:2E:40:50:17:FD:75:AC:C3:40:5D:CA:0F:00:86:2B:7D:43:B0
a=setup:active
a=rtpmap:99 H264/90000
a=candidate:1 1 udp 2013266431 ***.***.***.*** 39157 typ host
a=candidate:1 1 udp 2013266431 ***.***.***.*** 39157 typ host

[Sean DuBois]

Hi,

I would ask in the Janus discourse. Maybe try a mid of 0/1 and payload type of 111 but I don’t notice anything yet.

On May 3, 2023, at 13:54, Yang Fei <yfe...@gmail.com> wrote:

Hi,

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8996ba4e-e3d0-472b-bcab-30c374d44c75n%40googlegroups.com.

[Lorenzo Miniero]

Sounds like Janus is the answerer, here, so not the endpoint rejecting the answer (and this looks like a WHEP with the client-offering thing). Maybe the offerer doesn't like the a=inactive bit it gets back?

L.

[Daniel Möllmann]

Have you checked your answer candidates?
As it seems you have two times the same candidate present.