JavaScript: No connection information is added to SDP when there are no media descriptions

[Dan Virsén]

Hi,

I don't know if this is the right place to ask but I am hoping someone might have information on why all major browsers I have tried (Chrome, Firefox, and Safari) behave this way.

If I create a simple offer like this:
const pc = new RTCPeerConnection();
pc.createOffer().then(offer => console.log(offer.sdp));

The resulting SDP has no connection information ("c=" line).

If I create an SDP with a global c-line and no media descriptions and try set it as the local description I either get an error (Chrome, Safari) or the c-line is simply removed (Firefox). The error is something along the lines of "Failed to parse SessionDescription. c=IN IP4 x.x.x.x Expects m line". I can get the same error when I add a global c-line for an SDP that contains media descriptions. WebRTC (or at least the browser implementations I have tried this on) doesn't seem to like the idea of global connection information.

In a way I think that it doesn't make much sense to include connection information when there is no media, but the RFC seems pretty clear:

"A session description MUST contain either at least one "c=" line in each media description or a single "c=" line at the session level."

Does anyone know if the WebRTC specification dictates that this is the correct behaviour and (if so) why?

It's not a real issue but we do get warnings that the SDP is not valid in some environments when we use our WebRTC client to initiate a session without media, which is what made me curious.

/Dan

[Harald Alvestrand]

Do you have a real scenario where exchanging an offer/answer without any m= sections makes sense?

In general WebRTC has said "if you have no media sections, we're not going to establish a transport at all".

(We had a long discussion some years back about whether they should simply be forbidden, but we ended up permitting them, with the expected result of "no transport").

https://datatracker.ietf.org/doc/html/rfc8829#section-5.2.1 mentions c= lines only to note that they are included in m= sections, and always have the value "IN IP4 0.0.0.0". That section also notes that we generate no media sections if no RtpTransceivers are present. (That sentence forgot about data channels, but they are mentioned further down - if we have datachannels but no media sections, we do generate an m= section.)

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
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 visit https://groups.google.com/d/msgid/discuss-webrtc/d08de6b3-13f6-4ad6-9368-c02cbd5c9fafn%40googlegroups.com.

[Philipp Hancke]

c= must come before t= in https://www.rfc-editor.org/rfc/rfc4566#section-5.7 so the libWebRTC parser is expecting and enforcing that.

So this fails:

  const pc = new RTCPeerConnection();

  pc.createOffer().then(offer => pc.setLocalDescription({type: 'offer', sdp: offer.sdp + 'c=IN IP4 192.168.2.32\r\n'}));

while this works:

  const pc = new RTCPeerConnection();

  pc.createOffer().then(offer => pc.setLocalDescription({type: 'offer', sdp: offer.sdp.replace('t=0 0\r\n', 'c=IN IP4 192.168.2.32\r\nt=0 0\r\n')}));
Both are doing something that should be rejected, modifying the SDP passed to setLocalDescription.

If your remote system expects this, do such manipulations before sending the SDP there.

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVH9rJutKd-0H584eRLU8rjWk539r3dnvW%2BSBJWCN5ef2w%40mail.gmail.com.

[Dan Virsén]

There are a couple scenarios that rely on this that I work with. If they make sense or not I can't really say. :)

Text might be exchanged via SIP MESSAGE between old text-phones, DTMF via SIP INFO, or geo position data (PIDF-LO).

Like i said in the first post the missing c-line in the SDP only generates a warning but luckily the call is still connected correctly.