Vivienne,

See inline.

> After further testing I have determined what exactly seems to be
> happening. When the private client initiates a call to the public
> phone and the public phone then rings back the private phone,
> everything is fine. However if after a period of time, the public
> phone rings the private phone, there is no audio.    

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.

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...

    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.    

 

BTW, you can start ngrep with this script (do mkdir /var/log/sip first):

#!/bin/sh
nohup /path-to-ngrep/ngrep -t -W byline port 5060 2>&1 | rotatelogs /var/log/sip/sip 86400 &

 

You will then get easier to read output and everything is written to files (and they are rotate every day). 

If you could, it would be great to see a full (all messages) SIP ngrep dump for the following actions:

1. Public calls private, keeps the line open for 5 seconds and then private hangs up

2. Private calls public, keeps the line open for 5 seconds and then public hangs up

3. Step 1 once more.

 

I assume that you should experience #1 with no (one-way?which way?) audio, #2 is ok, #3 works based on your description.

> Im presuming this is somthing got to do with the fact that the
> RTPProxy doesnt know where the audio should be delivered or something
> got to do with ports?? My registration messages should last for many
> days. I have included the 200OK message sequences below when 2092
> (public) rings 2093(private) and theres no audio. I would like if
> someone could clarify if the "nortpproxy:yes" is appropriate and if
> the "c" field of the sdp is correct. Should the c field contain the
> public address of the natted client or the address of the rtpproxy?? 

nortpproxy:yes means that force_rtp_proxy() has been called for the message and c IP address has been replaced.

The c IP address should (when you proxy) be the public address of the rtpproxy.

g-)