On Fri, Jan 23, 2009 at 4:06 PM, Pascal Cassinelli <pcas33 at gmail.com> wrote: > Hi all, > > I'm working with Jan on this PJSIP porting to the embedded system and I > have a complicated question. I'll try to give you brief overview of the > situation and sketch out our problem. > > Cool. > Our embedded system consists of 2 Nios2 CPUs. One of them is running > uCLinux OS, the other one is without OS. These CPUs are sharing one > memory chip, but there is a rule set, that they do not interfere with > the memory area of the opposite one. To share data, there's a > proprietary interface implemented. It works in a way, that only a > pointer and size to the memory of the other CPU is exchanged and a > attach/detach mechanism ensures the data consistency. > > Okay. It's similar to the way TI OMAP works, i.e. ARM on the host side and TI DSP on the DPS side. > We want to use the PJSIP project to provide the VoIP functionality on > this system. The problem is, that only the uClinux has ethernet > connectivity, but it's rather loaded with other tasks. So we originally > planed to split the PJSIP between 2 CPUs - SIP and media_transport part > of pjmedia would run on the uClinux, while the rest of the pjmedia > library (media_session) would run on the nonOS CPU. Yes, I would also do it that way (and I did once with OMAP). We already ported > the pjlib library to the nonOS CPU, excluding the network functionality. > I would think that you would need to port PJLIB twice, one for the host side for PJSIP, PJSDP, PJNATH, etc, and once more for the DSP side for PJMEDIA only. > But then we find out, that splitting the pjmedia library could be a > little tricky. Because there's a lot of callback functions and other > dependencies inside the pjmedia library, and we would have to substitute > them with some virtual layer, that would communication agent between > these CPUs over our proprietary communication interface. > > Yes. I think that virtual layer to communicate data/events back and forth between host and DSP is needed regardless, so I don't think this is pjmedia specific. > So I want to ask, if you think this is a good approach or whether we > should find some other way, how to get the stuff working. I did it that way too, and I didn't see other alternatives either. > Maybe > implementing the virtual ethernet interface on the nonOS CPU and runnig > the PJSIP in one piece would be more easy and secure way? You mean to run SIP etc on the non-OS processor as well? Ah yeah, that could work! And it potentially can make maintenance easier in the long run too, since there's only one platform to support. We have two options to do this. One is to create a new SIP and media transport type to use the virtual interface, and another is to port the socket/networking API in PJLIB altogether to use the virtual interface. The first option should be straightforward if you only intend to use SIP and media UDP like transport, but unfortunately apart from SIP and media we also have other sockets as well, e.g. STUN and several others in PJNATH. These would need to be reimplemented if you need to use them. While some transport objects in PJNATH have been designed so that they can be reimplemented using custom transport, several others like NAT type detection and the old STUN in pjlib-util are not. So it could be tricky. The second option is to port all networking API in PJLIB to use the virtual interface. So it works something like if you call pj_sock_socket() to create socket, then it will instruct the host processor to create the actual socket with using some RPC. The good thing about this approach is you only need to implement this once, and you'll know that all existing transport objects should work, including future ones. The drawback of this approach is probaly the size of the networking API's that needs to be implemented. But probably it's not that much. Looking at Symbian as sample case again: - addr_resolv_symbian.cpp - ioqueue_symbian.cpp - ip_helper_symbian.cpp - sock_select_symbian.cpp - sock_symbian.cpp > The uClinux > CPU would just read data from RTP and SIP sockets and forward them to > the nonOS CPU. Yep. Cheers Benny > Or even something completely different? > > I'd deeply appreciate your suggestions > Pascal Cassinelli > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090123/55bd7dfe/attachment.html>
