<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o = "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2604" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>Vivienne,</DIV>
<DIV>See inline.</DIV>
<DIV><BR>> After further testing I have determined what exactly seems to
be<BR>> happening. When the private client initiates a call to the
public<BR>> phone and the public phone then rings back the private
phone,<BR>> everything is fine. However if after a period of time, the
public<BR>> phone rings the private phone, there is no
audio. <BR></DIV>
<DIV>This is interesting, because now your OKs seem to be correct. Please
note that BOTH the INVITE going to the private and the OK going back to the
public should have both Contact and c IP address changed for proxying to work.
</DIV>
<DIV>What is interesting, is that you say it works if you call the public phone
first once and then call the private right away. This doesn't really make sense
at all as long as the private phone rings when you have no audio. Because,
if it rings, the NAT is still open and SIP messaging is working...</DIV>
<DIV> When you say "no audio", does that mean in no
directions?! If you do a netstat -nlp | grep rtpproxy, you will
find four udp ports, two for each client (1 x RTCP, 1 x
RTP). Do a tcpdump port x on each of them to see if traffic goes
through the proxy. </DIV>
<DIV> </DIV>
<DIV>BTW, you can start ngrep with this script (do mkdir /var/log/sip
first):</DIV>
<DIV>#!/bin/sh<BR>nohup /path-to-ngrep/ngrep -t -W byline port 5060 2>&1
| rotatelogs /var/log/sip/sip 86400 &</DIV>
<DIV> </DIV>
<DIV>You will then get easier to read output and everything is written to files
(and they are rotate every day). </DIV>
<DIV>If you could, it would be great to see a full (all messages) SIP ngrep dump
for the following actions:</DIV>
<DIV>1. Public calls private, keeps the line open for 5 seconds and then private
hangs up</DIV>
<DIV>2. Private calls public, keeps the line open for 5 seconds and then public
hangs up</DIV>
<DIV>3. Step 1 once more.</DIV>
<DIV> </DIV>
<DIV>I assume that you should experience #1 with no (one-way?which way?) audio,
#2 is ok, #3 works based on your description.</DIV>
<DIV><BR>> Im presuming this is somthing got to do with the fact that
the<BR>> RTPProxy doesnt know where the audio should be delivered or
something<BR>> got to do with ports?? My registration messages should last
for many<BR>> days. I have included the 200OK message sequences below when
2092<BR>> (public) rings 2093(private) and theres no audio. I would like
if<BR>> someone could clarify if the "nortpproxy:yes" is appropriate and
if<BR>> the "c" field of the sdp is correct. Should the c field contain
the<BR>> public address of the natted client or the address of the
rtpproxy?? <BR></DIV>
<DIV>nortpproxy:yes means that force_rtp_proxy() has been called for the
message and c IP address has been replaced.</DIV>
<DIV>The c IP address should (when you proxy) be the public address of the
rtpproxy.</DIV>
<DIV>g-)</DIV>
<DIV> </DIV></BODY></HTML>