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(a)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(a)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(a)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(a)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(a)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(a)lists.iptel.org ; greger(a)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(a)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(a)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