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.BRViv
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,
> VivienneSend instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________
Serusers mailing list
serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusersSend instant messages to your online friends http://uk.messenger.yahoo.com
Send instant messages to your online friends http://uk.messenger.yahoo.com