8 Apr
2005
8 Apr
'05
6:33 p.m.
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-)