0

I need to store SDP structures returned by WebRTC. The specification does not define a maximum length but obviously the database needs one.

What is a reasonable length limit in this case? How do you generally go about deciding length limits in such undefined cases?

Community
  • 1
  • 1
Gili
  • 86,244
  • 97
  • 390
  • 689

3 Answers3

0

Usually, there is no need to store the whole SDP packet. The fact that there is not upper limit on the SDP packet length isn't an issue in most cases.

In this case, the simplest thing you could do is to use a blob.

plmaheu
  • 475
  • 5
  • 12
  • What sub-portions of the SDP are usually stored? In my experience, BLOB support tends to be awful in most databases (buggy implementations, poor performance, high memory usage, etc). – Gili Dec 10 '12 at 22:20
  • It is not stored at all. A SDP packet conveys information used to establish a session. It is usually used immediately and discarded. Why do you need to store it? – plmaheu Dec 11 '12 at 02:23
  • Look up WebRTC. Someone needs to pass the SDP between two web browsers (that cannot communicate directly with one another). That someone (the server) needs to put that SDP somewhere. – Gili Dec 11 '12 at 03:39
0

Unless the SessionId and Originator are changing in the SDP among other items it may not work.

The other stack might see the SDP and accept it but be unable to communicate with the remote client.

The SDP will most likely have to be re-written to some degree. If you want an alternative you can convert the SDP to XML and store the XML in the database and then use a function to query the xml and write it out as a SDP dynamicaly....

If XML is out of the question and you really only care about store see about using the filestream option in SQLServer http://www.databasejournal.com/features/mssql/filestream-and-filetable-in-sql-server-2012.html

Furthermore after reading this Draft Spec which is relevant only to WebRTC...

https://datatracker.ietf.org/doc/html/draft-nandakumar-rtcweb-sdp-00#page-3

I believe you will definitely have to rewrite portions of the SDP because of the Key Exchange used in the SDP.

Community
  • 1
  • 1
Jay
  • 3,276
  • 1
  • 28
  • 38
  • I'm sorry. I don't understand your answer. Why would SessionId or Originator need to change? What does "the other stack" refer to? Why should I care if one peer can't connect to the other? – Gili Dec 13 '12 at 18:28
  • Depending on how your clients are getting the actual media the mechanism doing that transport is the `stack` e.g. the player your client is using to consume the data your sending... if your using HTTP then it may not matter but if you were serving this SDP to client who was in a RTSP session then it would not work because the `stack` which is reading the SDP to determine information may utilize information from the SDP which would not be valid and thus would abort receiving. – Jay Dec 13 '12 at 19:10
  • Why would the SDP cease to be valid once stored in a database? I'm just acting as a proxy between two peers exchanging SDPs. – Gili Dec 13 '12 at 19:40
  • Because the SDP usually contains a field which is used to identify the session. It also has an IN address set to a source which is not you which may be looked at by the player. Check out the RFC http://tools.ietf.org/html/rfc4566 – Jay Dec 13 '12 at 19:51
  • I don't see a basis in the RFC for a client aborting the use of an SDP because the `c=` line did not match the server's IP address. If you disagree, please link to the specific section. In any case, I know WebRTC does not behave like this so this does not apply to this question. – Gili Dec 13 '12 at 20:03
  • Your actually looking at the wrong attribute... Look at `o= (originator and session identifier)` The Session identifier is used by some players or `stacks` – Jay Dec 13 '12 at 20:13
  • Sure, but where does the specification imply that clients may abort if the `o=` doesn't point to the server? – Gili Dec 13 '12 at 20:16
  • I'm not sure you understand... SDP does not transport the media.. in your case Http is transporting the SDP and then eventually the media. The player will download the SDP, read the information and determine how to continue... if your in `stack` is in Http mode if may ignore certain things present in the SDP however usually even when delivered over Http the SessionID will be generated for the Http session and not reused. So if that is the case the player will abort and because of the invalid sessionid. This is usually only a Network Timestamp in most cases making it easy to recalculate. – Jay Dec 13 '12 at 20:25
  • In the case of WebRTC, the SDP is downloaded from the server but the media is downloaded from the remote peer. In other words, the address in the SDP needs to point to the remote peer, not the server. Does that change anything for you? Also, why is the SessionId invalid? What **specifically** about it is invalid? – Gili Dec 13 '12 at 20:30
  • Well that makes the IN address seem like it would not need to be changed. But as for the sessionId I would reference their API to see if the seesionID persists or if you have to create a new one. The client might be expecting the sessionId to be in the SDP causing all of your clients to communicate on the same session... – Jay Dec 13 '12 at 20:34
  • Also check the updates in my answer.. I found a draft spec for WebRTC and just as I though there is information which changes in the SDP. – Jay Dec 13 '12 at 20:37
  • Trust me when I tell you, you're going down the wrong path. If you read up on WebRTC in more detail you'll understand I am just bootstrapping the initial SDP exchange (each peer gets their own SDP). Yes, the SDP changes over time, but that's past the bootstrapping process. The document you want to read is http://www.w3.org/TR/2012/WD-webrtc-20120821/ – Gili Dec 13 '12 at 20:53
  • So then if your only concerned about is storage I answered that as well. – Jay Dec 13 '12 at 21:06
  • So you're recommending the same behavior as, pboy... using the equivalent of a BLOB. Is that correct? – Gili Dec 13 '12 at 21:11
  • Kinda like blob but it would be faster and allow you to just write a file and read a file vs having to perform database transactions... – Jay Dec 13 '12 at 21:33
0

Answering my own question.

You can either estimate the maximum length using historical values, or use a BLOB. In my case, I ended up choosing a theoretical limit of 4000 bytes.

Gili
  • 86,244
  • 97
  • 390
  • 689
  • I'm writing a signaling server and trying to protect it against bad actors, which means I have to limit the allowed body size to a reasonable limit that holds most of webrtc offer/answer, so I wanted to know if this worked for you as you expected – Emad Elsaid Jul 11 '20 at 15:53
  • @EmadElsaid It's been 8 years. I honestly don't remember. – Gili Jul 12 '20 at 16:12