I have a need to connect to a TURN server over TLS within an ICE session. (And then eventually supporting TLS connection to TURN through an HTTP proxy.) There's two issues with this: pj_turn_sock is hardwired to pj_activesock. The ICE transport code, ice_strans, is hardwired to use turn_sock. Without changing the pjnath library code, if I could write my own transport to replace turn_sock that sits on top of a turn_session instance, but I would have to fork ice_strans to use my modified version of turn_sock. While it would be ideal to not have to change the pjnath code, I think it is warranted in this case for the sake of a simpler design. My approach will be to do the following: A simple abstraction layer, "async_socket", for pj_activesock and pj_ssl_socket that supports creation, read, send, start_connect, close, and user_data methods. Similarly, the on_data_read and on_connect_complete callbaks for each are abstracted out as well. The major differences between these implementations will be in how the underlying object is created - especially with regards to SSL parameters. Modify turn_sock to use my async_socket abstraction in place of the pj_activesock instance it uses now. pj_turn_sock_cfg has additional members for ssl configuration. Remove the ASSERT that guards pj_sock_turn_create from being called with PJ_TURN_TP_TLS. The value passed in for conn_type dictates which type of async_socket is created in the on_state callback. By abstracting out the differences between activesock and ssl_socket within turn_sock, no changes need to be made to the ICE code. Am I missing anything major or am I on the right course? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20130828/0aa16829/attachment-0001.html>
