On Fri, Apr 11, 2008 at 12:49 PM, Benny Prijono <bennylp at pjsip.org> wrote: > On Thu, Apr 10, 2008 at 4:44 PM, Net Dabbler <netdabbler at gmail.com> wrote: > > Hi all, > > > > We have been trying to interface PJSIP with the University of Essen's > > SCTP implementation. Can anyone offer advice on our approach? > > > > In order to add SCTP to the SIP side of things we have copied > > sip_transport_tcp.c to sip_transport_sctp.c, renamed all references to > > TCP in the new file to SCTP, and specified IPPROTO_SCTP in all the > > sock_socket calls. > > > > SCTP is then initialised by calling pjsip_sctp_transport_start. > > > > To decide which type of socket to create, sock_bsd.c checks the > protocol > > (TCP/SCTP) and calls either the system or SCTP library. The socket fd > is > > kept in a table so that future calls to socket methods are pointed to > > the appropriate library. Luckily, the SCTP library uses socket fd > values > > that start at 1023 and count down while the system starts low and > counts up. > > > > This seems to work well so far, but of course the media side of things > > is still using the old library because it doesn't use the transport > > manager setup on the SIP side. > > Hi Net, > > Good to know you've successfully integrated SCTP with PJSIP. By the > way, wouldn't it be possible to isolate the changes in the SIP SCTP > transport only? I mean you don't need to use ioqueue or sock_bsd.c if > you don't want to, you can just call the native SCTP API in your SIP > SCTP transport. This way the rest of the library doesn't even need to > be modified. Hi Benny, Thanks for your considered reply to such a long email. We altered sock_bsd.c for several reasons. Firstly, we didn't want to break the existing architecture by having socket calls anywhere but PJLIB. Secondly, we wanted to ensure we handled all PJMEDIA socket calls in sock_bsd.c. Thirdly, even though we could have created an ext_sock.c, this was a quick way to test the third party API and see if it worked. It is our intention to refactor at a later stage > > > Because the media side is less modular than the SIP side - and in > > particular, there is no TCP code we can simply duplicate and alter - we > > are thinking of changing the media socket calls from UDP-datagram to > > SCTP-seqpacket. Our hope is that this will work transparently for > > existing applications. > > Have you look at the new media transport extended APIs? [1] These new > APIs should allow the media transport to interact with the SDP (add > attributes, modify the SDP before it's sent, get both local and remote > SDP's when media is started, etc.) so I think this should allow SCTP > transport to be implemented modularly. Having said that, true there's > no TCP transport support in pjmedia yet. > > [1] > http://www.pjsip.org/pjmedia/docs/html/group__PJMEDIA__TRANSPORT__H.htm > OK, we'll examine the media transport extended APIs. > > > All of this is aimed at getting standard PJSIP applications to run > using > > the SCTP library. We have yet to consider what problems we will > > encounter when we try to incorporate multihoming using bindx etc. > > > > What we would like to know is does anyone (dis)agree with the approach > > we have taken, if anyone can foresee problems we may encounter, and > > indeed if anyone has any advice on how to proceed? > > I think the less modification you do to existing codes (e.g. > sock_bsd.c) the better and easier it is to maintain. Agreed - see my first answer above. > > > One other small matter you could also help us with is as follows. The > > system and SCTP socket fds are not interchangeable. For this reason, > > whenever a socket call is made, we first check the type of socket in > our > > table before despatching it. This is done in sock_bsd, which funnels > > most socket calls. Unfortunately there are other socket calls that > > bypass sock_bsd. ioctl is one. We have replaced each occurrence of > ioctl > > Right. Again probably this wouldn't happen if you isolate the SCTP > code in the SCTP transports, bypasssing the ioqueue and sock_bsd.c > (you may need to have dedicated worker thread(s)). > > > in PJSIP with a test for socket type before allowing it to proceed. Our > > problem is that we do not have control over third party libraries > > bundled with PJSIP. > > > > The question is: do these third party libraries (Speex etc) have access > > to the socket fd? > > I don't think so. Even third party libraries that works on transport > layer (such as OpenSSL and SRTP) don't have access to socket, so I > think we should be safe. > > Cheers > Benny OK, thanks for clearing up that point. Regards, ND P.S. Apologies for posting several times. Despite selecting the option that lets me see emails I've sent to the list, it appears to be not working for me which is why I posted again. > > > > If they have access we cannot guarantee that the system library will > not > > be called with an SCTP fd. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080411/0a511e02/attachment.html
