Another email - Sorry for posting so many timea! - Im sorry it was incorrect to says the messages are still the same. Since the extra fix_nated_contact hass been added in, the 200 ok message sent from SER to the public phone (i.e. the phone who is initiating the call) is different.

Below are the two 200 OK messages BEFORE the change was made:

U 84.203.148.14:5060 -> 84.203.148.146:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 84.203.148.146;branch=z9hG4bKf51e.b169be72

.0..Via: SIP/2.0/UDP 157.190.74.151;rport=5060;branch=z9hG4bKcd17ddd1b59ead

49..From: "2092" sip:2092@84.203.148.146;tag=aedc22bd5a3b510c..To: <sip:2

093@84.203.148.146>;tag=acd725e00242a605..Call-ID: 8ffc2d18b21870b3@157.190

.74.151..CSeq: 64735 INVITE..User-Agent: Grandstream BT100 1.0.5.18..Contac

t: sip:2093@172.16.3.31..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTION

S,INFO,SUBSCRIBE..Content-Type: application/sdp..Supported: replaces..Conte

nt-Length: 152....v=0..o=2093 8000 0 IN IP4 172.16.3.31..s=SIP Call..c=IN I

P4 172.16.3.31..t=0 0..m=audio 5004 RTP/AVP 0..a=sendrecv..a=rtpmap:0 PCMU/

8000/3..a=ptime:20..

U 84.203.148.146:5060 -> 157.190.74.151:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 157.190.74.151;rport=5060;branch=z9hG4bKcd

17ddd1b59ead49..From: "2092" sip:2092@84.203.148.146;tag=aedc22bd5a3b510c

..To: sip:2093@84.203.148.146;tag=acd725e00242a605..Call-ID: 8ffc2d18b218

70b3@157.190.74.151..CSeq: 64735 INVITE..User-Agent: Grandstream BT100 1.0.

5.18..Contact: sip:2093@172.16.3.31..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,

REFER,OPTIONS,INFO,SUBSCRIBE..Content-Type: application/sdp..Supported: rep

laces..Content-Length: 174....v=0..o=2093 8000 0 IN IP4 172.16.3.31..s=SIP

Call..c=IN IP4 84.203.148.146..t=0 0..m=audio 35016 RTP/AVP 0..a=sendrecv..

a=rtpmap:0 PCMU/8000/3..a=ptime:20..a=nortpproxy:yes..

Now the messages are as follows:

U 84.203.148.14:5060 -> 84.203.148.146:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 84.203.148.146;branch=z9hG4bKb9eb.e87f3706

.0..Via: SIP/2.0/UDP 157.190.74.151;rport=5060;branch=z9hG4bK14d3c4f08f811a

a6..From: "2092" sip:2092@84.203.148.146;tag=12bc28408336e179..To: <sip:2

093@84.203.148.146>;tag=34216f9b980666a6..Call-ID: a29762e6f24c12e9@157.190

.74.151..CSeq: 21848 INVITE..User-Agent: Grandstream BT100 1.0.5.18..Contac

t: sip:2093@172.16.3.31..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTION

S,INFO,SUBSCRIBE..Content-Type: application/sdp..Supported: replaces..Conte

nt-Length: 152....v=0..o=2093 8000 0 IN IP4 172.16.3.31..s=SIP Call..c=IN I

P4 172.16.3.31..t=0 0..m=audio 5004 RTP/AVP 0..a=sendrecv..a=rtpmap:0 PCMU/

8000/3..a=ptime:20..

U 84.203.148.146:5060 -> 157.190.74.151:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 157.190.74.151;rport=5060;branch=z9hG4bK14

d3c4f08f811aa6..From: "2092" sip:2092@84.203.148.146;tag=12bc28408336e179

..To: sip:2093@84.203.148.146;tag=34216f9b980666a6..Call-ID: a29762e6f24c

12e9@157.190.74.151..CSeq: 21848 INVITE..User-Agent: Grandstream BT100 1.0.

5.18..Contact: sip:2093@84.203.148.14:5060..Allow: INVITE,ACK,CANCEL,BYE,

NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Type: application/sdp..Support

ed: replaces..Content-Length: 174....v=0..o=2093 8000 0 IN IP4 172.16.3.31.

.s=SIP Call..c=IN IP4 84.203.148.146..t=0 0..m=audio 35002 RTP/AVP 0..a=sen

drecv..a=rtpmap:0 PCMU/8000/3..a=ptime:20..a=nortpproxy:yes..

So the contact header is re-written when SER forwards the 200 OK to the calling phone. However like I said, when the public phone rings the private phone, the public phone can hear voice but the private phone cant.

Apologies for sending so many emails in a row.

BR

Vivienne.

Vivienne Curran vivcurran@yahoo.co.uk wrote: Sorry I also should have mentioned that now when the public phone rings the private phone, the public client can hear voice but the private client can still hear nothing.

BR Viv

Vivienne Curran vivcurran@yahoo.co.uk wrote: Hi Greger (Sorry forgot to copy the serusers mailing list the 1st time),

I made that change and my on_reply_route now looks like this:

onreply_route[1] {

if (isflagset(6) && status=~"(180)|(183)|2[0-9][0-9]") { fix_nated_contact(); if (!search("^Content-Length:\ 0")) { force_rtp_proxy(); }; } else if (nat_uac_test("1")) { fix_nated_contact(); }; }

Unfortunately when I restarted rtpproxy, SER and reregistered my phones, I still had the same message dump.

U 84.203.148.146:5060 -> 157.190.74.151:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 157.190.74.151;rport=5060;branch=z9hG4bKcd

17ddd1b59ead49..From: "2092" sip:2092@84.203.148.146;tag=aedc22bd5a3b510c

..To: sip:2093@84.203.148.146;tag=acd725e00242a605..Call-ID: 8ffc2d18b218

70b3@157.190.74.151..CSeq: 64735 INVITE..User-Agent: Grandstream BT100 1.0.

5.18..Contact: sip:2093@172.16.3.31..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,

REFER,OPTIONS,INFO,SUBSCRIBE..Content-Type: application/sdp..Supported: rep

laces..Content-Length: 174....v=0..o=2093 8000 0 IN IP4 172.16.3.31..s=SIP

Call..c=IN IP4 84.203.148.146..t=0 0..m=audio 35016 RTP/AVP 0..a=sendrecv..

a=rtpmap:0 PCMU/8000/3..a=ptime:20..a=nortpproxy:yes..

Any more thoughts?

BR

Viv

"Greger V. Teigre" greger@teigre.com wrote: Look at this:

U 84.203.148.146:5060 -> 157.190.74.151:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 157.190.74.151;rport=5060;branch=z9hG4bKcd

17ddd1b59ead49..From: "2092" sip:2092@84.203.148.146;tag=aedc22bd5a3b510c

..To: sip:2093@84.203.148.146;tag=acd725e00242a605..Call-ID: 8ffc2d18b218

70b3@157.190.74.151..CSeq: 64735 INVITE..User-Agent: Grandstream BT100 1.0.

5.18..Contact: sip:2093@172.16.3.31..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,

REFER,OPTIONS,INFO,SUBSCRIBE..Content-Type: application/sdp..Supported: rep

laces..Content-Length: 174....v=0..o=2093 8000 0 IN IP4 172.16.3.31..s=SIP

Call..c=IN IP4 84.203.148.146..t=0 0..m=audio 35016 RTP/AVP 0..a=sendrecv..

a=rtpmap:0 PCMU/8000/3..a=ptime:20..a=nortpproxy:yes..

I assume this is where you get an error message. You haven't called fix_nated_contact() for this message, and in fact I believe there may be an error in the ONsip.org example where a line has been lost.

192. onreply_route[1] {

193.

194. if (isflagset(6) && status=~"(180)|(183)|2[0-9][0-9]") {

195. if (!search("^Content-Length:\ 0")) {

196. force_rtp_proxy();

197. };

198. } else if (nat_uac_test("1")) {

199. fix_nated_contact();

200. };

201. }

fix_nated_contact() should go in between line 194 and 195.

Could you please confirm that this works? I will look at the config file.

g-(

---- Original Message ---- From: Vivienne Curran To: serusers@lists.iptel.org ; greger@teigre.com Sent: Wednesday, April 06, 2005 04:12 PM Subject: Re: RTPProxy fails only for Private to Public communication

Just as an extra : I have a sniff of the message for when a public client (2092)rings a private client (2093)included at the bottom of this email. I cant see anything wrong with them but maybe it will shed more light on the matter.

Vivienne Curran vivcurran@yahoo.co.uk wrote: I changed the line modparam("nathelper", "rtpproxy_sock", "/var/run/rtpproxy.sock") to modparam("nathelper", "rtpproxy_sock", "udp:localhost:22222") and started the rtpproxy as ./rtpproxy -s udp from the relevant directory and this resulted in a series of "rtpp_command: no response from rtpproxy" and rtpproxy temporarily disabled" errors. If I return to the original mod param and start it as ./rtpproxy then it works but like I said when the private client rings the public client, I get "ERROR: send_rtpp_command: cant read reply from a RTP Proxy".

Any further ideas? Has anyone on the mailing list experienced this? I am using the script given in the onsip getting started doc for 0.9.0. but am using ser 0.8.14.

BR, Vivienne

Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Send instant messages to your online friends http://uk.messenger.yahoo.com

Send instant messages to your online friends http://uk.messenger.yahoo.com

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