16 Mar
2005
16 Mar
'05
5:08 a.m.
Hi All.
I'm using ser-0.9.1.
Is there a way to determine if mediaproxy is in use for an existing
SIP call so that re-INVITE messages can avoid losing audio when one or
the other SIP UAs are NATed?
We do not proxy RTP streams unless one or more SIP UAs are NATed. But
on re-INVITE messages I cannot figure out how to test the destination
of the re-INVITE for the UAs NAT status.
I've scoured the archives and found a few related articles
http://lists.iptel.org/pipermail/serdev/2004-March/001515.html
http://lists.iptel.org/pipermail/serusers/2004-March/006806.html
But nothing has led me to a solution. I cannot just use
lookup("location") and test the nat_flag since that won't always work
on re-INVITEs. A mediaproxy function for something like
is_existing_session() would be awesome to lookup the Call-ID in the
existing mediaproxy sessions.
What am I missing?
Regards,
Paul
16 Mar
16 Mar
4:25 p.m.
Hi Paul!
If you use the nathelper module, you can use force_rtpproxy with the 'l'
parameter. Check nathelper.c for documentation.
I don't know if there is an equivalent feature in the mediaproxy module.
regards,
klaus
Java Rockx wrote:
Hi All.
I'm using ser-0.9.1.
Is there a way to determine if mediaproxy is in use for an existing
SIP call so that re-INVITE messages can avoid losing audio when one or
the other SIP UAs are NATed?
We do not proxy RTP streams unless one or more SIP UAs are NATed. But
on re-INVITE messages I cannot figure out how to test the destination
of the re-INVITE for the UAs NAT status.
I've scoured the archives and found a few related articles
http://lists.iptel.org/pipermail/serdev/2004-March/001515.html
http://lists.iptel.org/pipermail/serusers/2004-March/006806.html
But nothing has led me to a solution. I cannot just use
lookup("location") and test the nat_flag since that won't always work
on re-INVITEs. A mediaproxy function for something like
is_existing_session() would be awesome to lookup the Call-ID in the
existing mediaproxy sessions.
What am I missing?
Regards,
Paul
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4:29 p.m.
Klaus,
Thanks. You're right, I don't think mediaproxy has any such test.
Anyhow, late last night I was discussing this with Zeus Ng and he
shared his code with how he handles this.
Here is verbatim, what he told me. It seems to work, but I hope it
doesn't break anything.
Regards,
Paul
How about something like this.
With the initial INVITE,
... Route processing ...
if (caller is natted) {
subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/');
}
call nathelper or mediaproxy
t_on_reply(nat reply route);
t_relay();
In your reply route,
if (callee is natted) {
subst('/From:(.*)<(.*)>(.*)/From:\1<\2>;nat=yes\3/');
call nathelper or mediaproxy
... Other processing ...
In your loose route,
if (loose_route()) {
if (method=="INVITE") {
if (search("my_ser_detect_nat=yes") || (sdp in private address )) {
call nathelper or mediaproxy
}
}
on reply route
t_relay()
}
On Wed, 16 Mar 2005 15:25:35 +0100, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
Hi Paul!
If you use the nathelper module, you can use force_rtpproxy with the 'l'
parameter. Check nathelper.c for documentation.
I don't know if there is an equivalent feature in the mediaproxy module.
regards,
klaus
Java Rockx wrote:
Hi All.
I'm using ser-0.9.1.
Is there a way to determine if mediaproxy is in use for an existing
SIP call so that re-INVITE messages can avoid losing audio when one or
the other SIP UAs are NATed?
We do not proxy RTP streams unless one or more SIP UAs are NATed. But
on re-INVITE messages I cannot figure out how to test the destination
of the re-INVITE for the UAs NAT status.
I've scoured the archives and found a few related articles
http://lists.iptel.org/pipermail/serdev/2004-March/001515.html
http://lists.iptel.org/pipermail/serusers/2004-March/006806.html
But nothing has led me to a solution. I cannot just use
lookup("location") and test the nat_flag since that won't always work
on re-INVITEs. A mediaproxy function for something like
is_existing_session() would be awesome to lookup the Call-ID in the
existing mediaproxy sessions.
What am I missing?
Regards,
Paul
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
30 Mar
30 Mar
2:15 p.m.
On Tue, 15 Mar 2005 22:08:34 -0500, Java Rockx <javarockx(a)gmail.com> wrote:
Is there a way to determine if mediaproxy is in use
for an existing
SIP call so that re-INVITE messages can avoid losing audio when one or
the other SIP UAs are NATed?
I'm working on reinvite with ser and mediaproxy, but on an older ser
(pre 0.8.14) version.
What I've seen is, is that this is a bug/feature in the mediaproxy
itself where a new INVITE will be ignored on an existing call. I've
fixed this on our development proxy a long time ago and can't remember
how much I had to fix.
When I'm done I will port it to the current source (if necessary) with
also some other stuff I'm working on.
--
Andreas Sikkema
6:10 p.m.
Hello,
Andreas Sikkema wrote:
What I've seen is, is that this is a bug/feature
in the mediaproxy
itself where a new INVITE will be ignored on an existing call. I've
fixed this on our development proxy a long time ago and can't remember
how much I had to fix.
We had this problems especially for handling codec switches, for example
from G.729/G.711 to T.38 and back, and also for conditional call
forwards, where the second INVITE had another destination IP for RTP.
I posted a fix some time ago, see
http://lists.iptel.org/pipermail/serdev/2004-October/002991.html
Sorry, never got concrete feedback from ag-projects about this.
But note that we've faced some other problems, especially for T.38:
Mediaproxy waits for RTP packets from both parties before starting to
relay the traffic, but in T.38 the receiver only answers when it gets
some T.38 traffic, so we had to force the forwarding of RTP packets in
rtphandler.py:handle_read() to the visible IP of the other party before
that one could sign in.
Hope this helps,
Andy
7207
days inactive
7221
days old
4 comments
4 participants
participants (4)
-
Andreas Granig -
Andreas Sikkema -
Java Rockx -
Klaus Darilion