[Nice] New SDP parsing API

Wed Feb 6 17:06:17 PST 2013

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

-------------- 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/20130206/21dada30/attachment-0001.pgp>