Consider broader use - generating SDP not just parsing, not just webrtc

[t-ray]

I'd like to use this crate to parse sdp offers, and generate sdp's answers. The current functionality is mostly there, but there are some things that simply cannot be manually constructed in it's current form.

For example, one cannot use the object model to construct server reflexive/stun candidates to emit the following line:
a=candidate:297898e4296c74660bb3ab65d8da90ec 1 udp 1694498815 38.110.49.98 9200 typ srflx raddr 172.18.0.1 rport 56040. SdpAttributeCandidate defines a new method, but does not accept remote address or port values. Instead, those attributes are accessed via non-public setters. So the only way that I can see to construct such an instance would be to generate the string for the line, then parse that line via parse_attribute.

Furthermore, I understand this project is specifically designed for use with webrtc, but could also be very helpful in dealing with SIP sdp payloads. Again, it's most of the way there, but a few more codecs would need to be supported (such as G729).

[nils-ohlmeier]

I think exposing these setters as public should be easy enough. I'm guessing we didn't run into this issue so far as our current implementation actually does pass around strings for ICE candidates. But we want to change that in the future as well.

We had the discussion about non-webrtc support a couple of times. If think meanwhile I'm of the opinion that we could down that path, but only with build flags so that the default build still results in a webrtc only binary.

@na-g any thoughts on these topics?

[na-g]

I have no objections to adding the setters. We need to discuss exactly how these feature flags would work.

[thutchmoto]

I can confirm in my local repo that making the setters as public was sufficient for me to generate the answer I needed.

In regards to the other audio format - Adding 18/G729 to the parse_media function allowed me to parse an SDP offer made from Bandwidth.