Chronological Thread 

< Chronological >      < Thread >

---

On 30 May 2014, at 20:32, Lorenzo Miniero
<lminiero AT gmail.com>
wrote:

> Hi again,
>
> I knew my question was silly... giving a better look at the examples, and
> at the way Chrome and Firefox make use of the library, I realized AF_CONN
> is what I need.
Yepp, that is the way to go. You can look at programs/ekr_peer.c, which was
the example
for ekr to implement the stuff in Firefox.

Let me know if you have more questions. Please be sure to use the latest
version from svn...

Best regards
Michael
>
> Sorry about that, feel free to disregard this post,
> Lorenzo
>
>
>
> 2014-05-30 11:44 GMT+02:00 Lorenzo Miniero
> <lminiero AT gmail.com>:
> Hello everybody,
>
> first of all, I apologize in advance if this may be a silly question (it
> probably is!), but I've just recently started studying the library and so
> I'm trying to understand how it could be used for what I need. I'm working
> on a WebRTC gateway, and I'm interested in implementing support for
> DataChannels. Since both Chrome and Firefox are using usrsctp for the
> purpose, it made sense to follow the same road.
>
> That said, I've been studying the library and some examples, and there's a
> step that I'm missing that is currently confusing me. If I've understood
> correctly, the library provides a user space UDP encapsulation of SCTP
> messages. This means that the library itself takes care of sending and
> receiving UDP messages, and handling the SCTP stuff accordingly. In my
> case, though, considering the WebRTC scenario, ICE and DTLS are involved
> too: specifically, I'm using libnice for ICE and openssl for DTLS. This
> means that the actual communication is taken care of by libnice, and that
> the BIO I/O abstraction in openssl is used for implementing DTLS on top of
> it (since openssl can't take care of the network stuff either for the same
> reason).
>
> This is where I got lost with usrsctp. Direct UDP encapsulation apparently
> is not viable, since the SCTP message should first of all be encrypted via
> DTLS, and only then transported to the destination (in my case, even using
> a different networking component). I guess that a way to do so could be to
> employ a local UDP "channel" for the sole purpose of retrieving the SCTP
> payload to then encapsulate in DTLS and then send to the peer, and
> viceversa, but I'm not sure this would work as expected.
>
> Is there any way to configure usrsctp to work somehow like the openssl BIOs
> work, that is returning/handling SCTP messages that can be sent/received
> out-of-band on a virtual channel, or is the local UDP intermediary the only
> way to handle my specific scenario?
>
> Thanks in avcance for any help you'll be able to provide me with,
> Lorenzo
>
> _______________________________________________
> sctp-discussion mailing list
> sctp-discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/sctp-discussion

---

• [SCTP-Discussion] Alternatives to UDP encapsulation?, Lorenzo Miniero, 05/30/2014
  • [SCTP-Discussion] Re: Alternatives to UDP encapsulation?, Lorenzo Miniero, 05/30/2014
    • Re: [SCTP-Discussion] Alternatives to UDP encapsulation?, Michael Tuexen, 05/30/2014

---

Archive powered by MHonArc 2.6.19+.