[Nice] New SDP parsing API

Wed Feb 6 16:53:32 PST 2013

Thanks I like the layered sdp generate/parse calls! We may be able to
leverage them for our GridFTP extension that passes candidates over the
ftp control channels, instead of inventing our own format.

Using sdp-example, I was disappointed that the raw SDP wasn't printed
initially, just the base64 encode. It did get printed after pasting to
the other end, but it played strangely with my expectation because I
was curious what the SDP looked like and I wasn't planning on running
two copies and doing the full negotiation. I'd prefer if it printed
SDP on the send end also, although the user might be confused
and copy/paste that instead of the encoded data. Even better
if it doesn't use base64 at all, but handling the multi-line data is
more work and it's more fragile to copy/paste. I guess I'm being silly
to analyze a simple example this much; probably time to go home :).

-Bryce

On Tue, 05 Feb 2013 18:30:20 -0500
Youness Alaoui <youness.alaoui at collabora.co.uk> wrote:
> I have added 5 new API calls :
> 
> NiceCandidate *nice_agent_get_default_local_candidate (agent,
> stream_id, component_id);
> gchar * nice_agent_generate_local_sdp (agent);
> gchar * nice_agent_generate_local_stream_sdp (agent, stream_id,
> include_non_ice); int nice_agent_parse_remote_sdp (agent, sdp);
> GSList * nice_agent_parse_remote_stream_sdp  (agent, stream_id, sdp,
> &ufrag, &pwd); NiceCandidate * nice_agent_parse_remote_candidate_sdp
> (agent, stream_id, sdp);
> 
> You can now request the default candidate for each component, and
> generate the sdp for a single stream (the include_non_ice boolean
> makes it add/skip the m=, c= and a=rtcp: lines), and generate the sdp
> for a single candidate (there is no \n in that line).
> You can also parse a stream's SDP and a candidate's SDP line. The
> parsers for those 2 functions will *not* set the
> candidates/credentials, instead they will simply return them so the
> user can set them manually if he wants to. The previous
> parse_remote_sdp/generate_local_sdp are unchanged, and will set the
> candidates on the agent.
> 
> I have also made the m= line use ICE/SDP instead of RTP/AVP, this
> makes more sense and forces people to mangle it to the right value.
> 
> I have updated the code on the git repository and the documentation
> on my webpage. Any other comments are welcome!
> repo: http://cgit.collabora.com/git/user/kakaroto/libnice.git/log/
> docs: http://people.collabora.com/~kakaroto/libnice-docs/
> 
> Thanks.
> Youness.
> 
> On 02/05/2013 02:03 PM, Youness Alaoui wrote:
> > On 02/05/2013 03:55 AM, Olivier Crête wrote:
> >> Hi,
> >>
> >> Good work!
> > Thanks :)
> > 
> >>
> >> On Mon, 2013-02-04 at 23:39 -0500, Youness Alaoui wrote:
> >>> To summarize the new API, you can now call :
> >>>    sdp_string = nice_agent_generate_local_sdp(agent);
> >>> which will generate a single string containing a listing of all
> >>> your streams, components, their credentials and candidates. You
> >>> can then send that string as is to a remote user, which would
> >>> call :
> >>
> >> This should be available at least be per-media, ideally even
> >> per-candidate (to support trickling). Having it per-media without
> >> the m= line means that one can just put the blob from libnice
> >> inside you SDP without having to mangle it. Possibly also add some
> >> API to get the recommended default candidate (ie, the lowest
> >> priority).
> > 
> > Humm... That's a good point. So how would you suggest it? An API
> > like this : nice_agent_generate_local_sdp_stream()
> > nice_agent_generate_local_sdp_candidate()
> > with parse_remote_sdp_stream/parse_remote_sdp_candidate ?
> > That would work.
> > For the default, I'm not sure, it's easy enough to find the lowest
> > priority candidate... although it gets confusing when you need to
> > find the equivalent default candidate for other components (which
> > must have the same foundation as the default for the first
> > component). If I add it, I'm thinking of :
> > NiceCandidate *nice_agent_get_default_candidate(agent, stream,
> > component);
> > 
> > 
> >>
> >>> The SDP can also be used in a SIP call, but of course, you'd need
> >>> to add your codec list to it and parse it to change the 'm' line
> >>> to add the payload types to it. Other than that, it's a valid SDP
> >>> according to the ICE RFC.
> >>
> >> Also, not everyone uses the RTP/AVP profile, for example WebRTC
> >> mandates RTP/AVPF, I would just not provide an m= line at all.
> > I could put something else there as placeholder like "ICE/SDP". I
> > used "RTP/AVP" because that's what they had in the example on the
> > ICE RFC. and either way, whoever uses that will have to replace the
> > m= line anyways, so it didn't matter what was in there, as long as
> > it had the stream name. I can't remove the m= line though because
> > if you want a single SDP for the whole agent, then you need to
> > differentiate between the streams, and it also has the name of the
> > stream so I can select it. Without that generate/parse single
> > string, then the sdp-example would be a lot more complicated to
> > handle.
> > 
> > 
> >>
> >> Also, please check
> >> https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-02 as I believe
> >> this will become major user (it's the candidate API for WebRTC).
> >>
> > Oh that's interesting! I'll have a look thanks!
> > 
> > Thanks a lot for your comments! I thought you were on vacation
> > though :p
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > nice mailing list
> > nice at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/nice
> > 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/nice/attachments/20130206/28105eca/attachment.pgp>