9 Oct
2012
9 Oct
'12
3:30 p.m.
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