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.com
http://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