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