Giovanni,
Interesting. The onsip config files have not been tested with eyebeam AFAIK.
I would intuitively expect that the video INVITE should not contain a To
tag, but I haven't looked into the RFC-specification for this case. Does
anyone know?
Please note that nathelper/rtpproxy ver 0.9.0 do not have support for video
streams (mediaproxy has). CVS head versions of both have that support. I do
not know if backporting nathelper/rtpproxy to 0.9.0 involves any work, and
I'm not aware of any efforts to do so. Maxim?
g-)
Giovanni Balasso wrote:
Hi serusers
I have problem with NAT and eyebeam video streams. I have all my
audio issues with nat fixed using onsip-like config files, audio
sessions work as they should with no problems. But when I try to send
video with eyebeam during an audio session, nothing happens. Actually
eyebeam sends another INVITE, ser processes this INVITE in
loose_route section by force_rtp_proxy("l"), and rtpproxy logs the
request trying to use the same ports of audio stream.
Does anybody knows if this is the point (ie. rtpproxy should open new
ports for video stream)? How should I tell rtpproxy to use other
ports?
One stranger thing is that when I call someone inside the same NAT
video works even forcing use of rtpproxy.
Thanks for help
ser.cfg sections:
if (loose_route()) {
if (has_totag() && (method=="INVITE" ||
method=="NOTIFY")) {
if (nat_uac_test("19")) {
setflag(6);
force_rport();
fix_nated_contact();
};
if (method=="INVITE") {
force_rtp_proxy("l");
};
};
t_on_reply("1");
t_relay();
break;
};
}