Hello,
the signaling shows traffic going from public IP (caller) to private IP (kamailio) then back to public IP (callee). So it is a bit of complex routing if you keep it like this. The best is to get it done working with kamailio, rtpproxy and mcu on their public
ip, because they have such already. Then you can think of moving to use some private networks.
Your fourth bullet below is not clear for me: the clients should have visibility to sip server in order to register and call, but you say not, maybe just a typo.
Also, I would recommend to start with latest kamailio 3.3.1 version, 3.2.0 is very old, if you really want that release series, the use latest 3.2.x, not 3.2.0.
Cheers,
Daniel
On 10/9/12 1:36 PM, MARINA SERRANO MONTES wrote:
Hi Daniel:
The network is:
- MCU is running in a private network with IP's (10.95.94.142 and 10.95.94.143) and public IP's 195.235.93.166 and 195.235.93.161.
- SIP server and rtpproxy are running in another network: 10.95.94.92, with public IP: 195.235.93.8.
- SIP server, rtpproxy and MCU has visibility between them.
- Clients have not visibility with sip server and MCU, and they try register, invite,….using the public IP: 195.235.93.8 (public IP of rtpproxy)
- When I have not use MCU, only 2 participants, the video and audio is routing OK.
- I can verify using web browser conference in MCU that it is sending RTP traffic (out traffic).
Thank you very much.
Br,
Marina
I attach the sip messages of a call with/without MCU:
...
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu