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 the functionality of 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 [Linux OpenSuse 10.3] 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 is still using the old library because it doesn't use the transport manager setup on the SIP side. 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. 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? 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 handles most socket calls. Unfortunately there are other socket calls that bypass sock_bsd. ioctl is one. We have replaced each occurrence of ioctl 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? If they have access we cannot guarantee that the system library will not be called with an SCTP fd. Regards, Net Dabbler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080411/b31e9773/attachment.html