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. > 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 > 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. > 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 > If they have access we cannot guarantee that the system library will not > be called with an SCTP fd. > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >
