[Nice] New SDP parsing API

Fri Feb 22 14:28:56 PST 2013

Hey everyone. I plan on making a release later today with the new examples and
SDP parsing API. If you have any comments/requests, best say them now before the
release!
Thanks!

On 02/06/2013 08:06 PM, Youness Alaoui wrote:
> On 02/06/2013 07:53 PM, Bryce Allen wrote:
>> 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.
> Cool! I'm glad you like the API!
> 
>>
>> 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 :).
> haha! I actually just had a script file to transform the base64 when I was testing :
> echo $1 | base64 -d -
> I understand what you mean, but yes, I didn't want to put it there because I
> didn't want people to get confused, or copy/paste the wrong thing.. and I liked
> the feeling of the base64 as being "your unique identifier" kind of thing.
> Also, I thought of base64 when I was trying to come up with a way of showing the
> multiline sdp, whether or not to use a single dot on a line to signify that it's
> done, or an empty line, what would happen if someone pressed enter by mistake,
> or if they didn't see the dot, etc.. it was just too complicated and not worth
> it. Mostly, I didn't want to make a 'simple example about libnice' into a
> complex string parsing example... base64 adds a single line of code, so it's
> overall better.
> As for showing the SDP..it's an example, should be easy enough to edit it to
> make it print it if you're curious about that stuff :p But I didn't notice it
> was printing the remote sdp when it gets set.. that was a debug line that I
> forgot to remove, I will remove it now.. although I know it has the opposite
> effect of what you were saying :p
> 
> Thanks
> Youness.
> 
>>
>> -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
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> nice mailing list
>>> nice at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/nice
> 
> 
> 
> 
> _______________________________________________
> 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: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20130222/57178eb3/attachment.pgp>