I am using the onsip ser.cfg for mediaproxy. All seems OK when I call between two X-Lite clients. However calls between X-Lite and a Sipura 2000 have no audio in either direction. Both the X-Lite clients and the Sipura are on the same network behind NAT and going out to the SER/Mediaproxy server which has a public IP. SER and Mediaproxy are on the same server.
I've tested SJPhone to Sipura and there's no audio also, so it seems like a Sipura issue.
I've set NAT mapping enable and NAT Keep Alive enable to yes on the Sipura.
What am I missing?
Regards
Cameron
Cameron, Try turning *off* Sipura NAT mapping. The onsip config files assume that clients should not do NATing. (However, if the clients do it properly, it will work. Sipura has many various NAT options you can turn on and off) Note that if you configure clients to use NAT mapping, STUN, etc, your experiences with audio may be completely related to how the clients handle NAT, not mediaproxy. If the client itself detects its own public IP (or you configure it manually), mediaproxy will not detect NAT and will not proxy the call. I believe xlite default is configured with STUN.
If you want Sipura to use STUN (and thus mediaproxy only handles symmetric NATs): Under admin - advanced - SIP in Sipura, you will find: NAT Support Parameters Handle VIA received: yes Handle VIA rport: yes Insert VIA received: yes Insert VIA rport: yes Substitute VIA Addr: yes Send Resp To Src Port: no STUN Enable: yes STUN Test Enable: yes STUN Server: your stun serve EXT IP: EXT RTP Port Min: NAT Keep Alive Intvl: 20
These settings should work with the onsip.org config file.
g-)
----- Original Message ----- From: "Cameron Beattie" kjcsb@orcon.net.nz To: serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 08:26 AM Subject: [Serusers] SER & Mediaproxy: XLite - Audio OK, Sipura - No audio
I am using the onsip ser.cfg for mediaproxy. All seems OK when I call between two X-Lite clients. However calls between X-Lite and a Sipura 2000 have no audio in either direction. Both the X-Lite clients and the Sipura are on the same network behind NAT and going out to the SER/Mediaproxy server which has a public IP. SER and Mediaproxy are on the same server.
I've tested SJPhone to Sipura and there's no audio also, so it seems like a Sipura issue.
I've set NAT mapping enable and NAT Keep Alive enable to yes on the Sipura.
What am I missing?
Regards
Cameron _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Thanks for the tips.
I have changed the NAT settings on the SPA2000 back to no NAT. I couldn't find the via settings you referred to so I upgraded the firmware (from 2.0.10e to 2.0.13g) and there they were. Hmmm. Was I just blind or were they really not there before???
X-Lite is not configured to use stun. I've still got no audio either way with the settings below. The problem exists with and without stun settings:
Admin > advanced > Line 1 NAT Settings NAT mapping enable: no NAT keep alive enable: no
Admin > advanced > SIP NAT Support Parameters Handle VIA received: yes Handle VIA rport: yes Insert VIA received: yes Insert VIA rport: yes Substitute VIA Addr: yes Send Resp To Src Port: no STUN Enable: no STUN Test Enable: no STUN Server: EXT IP: EXT RTP Port Min: NAT Keep Alive Intvl: 20
Any further pointers would be greatly appreciated.
Regards
Cameron
----- Original Message ----- From: "Greger V. Teigre" greger@teigre.com To: "Cameron Beattie" ext_news@appsfarm.com; serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 6:44 PM Subject: Re: [Serusers] SER & Mediaproxy: XLite - Audio OK, Sipura - No audio
Cameron, Try turning *off* Sipura NAT mapping. The onsip config files assume that clients should not do NATing. (However, if the clients do it properly, it will work. Sipura has many various NAT options you can turn on and off) Note that if you configure clients to use NAT mapping, STUN, etc, your experiences with audio may be completely related to how the clients handle NAT, not mediaproxy. If the client itself detects its own public IP (or you configure it manually), mediaproxy will not detect NAT and will not proxy the call. I believe xlite default is configured with STUN.
If you want Sipura to use STUN (and thus mediaproxy only handles symmetric NATs): Under admin - advanced - SIP in Sipura, you will find: NAT Support Parameters Handle VIA received: yes Handle VIA rport: yes Insert VIA received: yes Insert VIA rport: yes Substitute VIA Addr: yes Send Resp To Src Port: no STUN Enable: yes STUN Test Enable: yes STUN Server: your stun serve EXT IP: EXT RTP Port Min: NAT Keep Alive Intvl: 20
These settings should work with the onsip.org config file.
g-)
----- Original Message ----- From: "Cameron Beattie" kjcsb@orcon.net.nz To: serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 08:26 AM Subject: [Serusers] SER & Mediaproxy: XLite - Audio OK, Sipura - No audio
I am using the onsip ser.cfg for mediaproxy. All seems OK when I call between two X-Lite clients. However calls between X-Lite and a Sipura 2000 have no audio in either direction. Both the X-Lite clients and the Sipura are on the same network behind NAT and going out to the SER/Mediaproxy server which has a public IP. SER and Mediaproxy are on the same server.
I've tested SJPhone to Sipura and there's no audio also, so it seems like a Sipura issue.
I've set NAT mapping enable and NAT Keep Alive enable to yes on the Sipura.
What am I missing?
Regards
Cameron _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Cameron,
Can you post an complete call trace using ngrep or post a pcap file on port 5060 using tcpdump?
Regards, Paul
On 4/19/05, Cameron Beattie kjcsb@orcon.net.nz wrote:
Thanks for the tips.
I have changed the NAT settings on the SPA2000 back to no NAT. I couldn't find the via settings you referred to so I upgraded the firmware (from 2.0.10e to 2.0.13g) and there they were. Hmmm. Was I just blind or were they really not there before???
X-Lite is not configured to use stun. I've still got no audio either way with the settings below. The problem exists with and without stun settings:
Admin > advanced > Line 1 NAT Settings NAT mapping enable: no NAT keep alive enable: no
Admin > advanced > SIP NAT Support Parameters Handle VIA received: yes Handle VIA rport: yes Insert VIA received: yes Insert VIA rport: yes Substitute VIA Addr: yes Send Resp To Src Port: no STUN Enable: no STUN Test Enable: no STUN Server: EXT IP: EXT RTP Port Min: NAT Keep Alive Intvl: 20
Any further pointers would be greatly appreciated.
Regards
Cameron
----- Original Message ----- From: "Greger V. Teigre" greger@teigre.com To: "Cameron Beattie" ext_news@appsfarm.com; serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 6:44 PM Subject: Re: [Serusers] SER & Mediaproxy: XLite - Audio OK, Sipura - No audio
Cameron, Try turning *off* Sipura NAT mapping. The onsip config files assume that clients should not do NATing. (However, if the clients do it properly,
it
will work. Sipura has many various NAT options you can turn on and off) Note that if you configure clients to use NAT mapping, STUN, etc, your experiences with audio may be completely related to how the clients
handle
NAT, not mediaproxy. If the client itself detects its own public IP (or you configure it manually), mediaproxy will not detect NAT and will not proxy the call. I believe xlite default is configured with STUN.
If you want Sipura to use STUN (and thus mediaproxy only handles
symmetric
NATs): Under admin - advanced - SIP in Sipura, you will find: NAT Support Parameters Handle VIA received: yes Handle VIA rport: yes Insert VIA received: yes Insert VIA rport: yes Substitute VIA Addr: yes Send Resp To Src Port: no STUN Enable: yes STUN Test Enable: yes STUN Server: your stun serve EXT IP: EXT RTP Port Min: NAT Keep Alive Intvl: 20
These settings should work with the onsip.org http://onsip.org config
file.
g-)
----- Original Message ----- From: "Cameron Beattie" kjcsb@orcon.net.nz To: serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 08:26 AM Subject: [Serusers] SER & Mediaproxy: XLite - Audio OK, Sipura - No
audio
I am using the onsip ser.cfg for mediaproxy. All seems OK when I call between two X-Lite clients. However calls between X-Lite and a Sipura
2000
have no audio in either direction. Both the X-Lite clients and the
Sipura
are on the same network behind NAT and going out to the SER/Mediaproxy server which has a public IP. SER and Mediaproxy are on the same server.
I've tested SJPhone to Sipura and there's no audio also, so it seems
like
a Sipura issue.
I've set NAT mapping enable and NAT Keep Alive enable to yes on the Sipura.
What am I missing?
Regards
Cameron _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Thanks for your replies. Some other things I've noticed: - Contact: public IP for X-Lite and private for Sipura - Received: blank for X-Lite and public IP with port of 1025 for Sipura - CallID: SIP proxy domain name for X-Lite and private IP for Sipura
Why are these set differently for the different clients? I'm guessing that it's the Contact record that is screwing up NAT? I can post the ngrep if that still is required.
serctl ul show ~~~/Contact~~~~ .../Record... ...Record(0xb613ed34)... domain: 'location' aor : 'user1' ~~~Contact(0xb613edc4)~~~ domain : 'location' aor : 'user1' Contact : 'sip:user1@60.234.198.XXX:5061' Expires : 1681 q : Call-ID : '47041BCBF01640CBABEDD8D1385DF9D3@domain.com' CSeq : 27061 replic : 0 User-Agent: 'X-Lite release 1103m' received : '' State : CS_SYNC Flags : 0 next : (nil) prev : (nil) ~~~/Contact~~~~ .../Record... ...Record(0xb6140f10)... domain: 'location' aor : 'beattiek' ~~~Contact(0xb613eb8c)~~~ domain : 'location' aor : 'user2' Contact : 'sip:user2@192.168.0.11:5060' Expires : 3565 q : Call-ID : 'ea8b8415-fa111ada@192.168.0.11' CSeq : 2 replic : 0 User-Agent: 'Sipura/SPA2000-2.0.13(g)' received : 'sip:60.234.198.xxx:1025' State : CS_SYNC Flags : 1 next : (nil) prev : (nil)
Regards
Cameron <snip> ----- Original Message ----- From: Java Rockx To: Cameron Beattie Cc: serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 11:12 PM Subject: Re: [Serusers] SER & Mediaproxy: XLite - Audio OK, Sipura - No audio
Cameron,
Can you post an complete call trace using ngrep or post a pcap file on port 5060 using tcpdump?
Regards, Paul <snip>
Yes, the ngrep will still help.
Regards, Paul
On 4/19/05, Cameron Beattie kjcsb@orcon.net.nz wrote:
Thanks for your replies. Some other things I've noticed:
- Contact: public IP for X-Lite and private for Sipura
- Received: blank for X-Lite and public IP with port of 1025 for Sipura
- CallID: SIP proxy domain name for X-Lite and private IP for Sipura
Why are these set differently for the different clients? I'm guessing that it's the Contact record that is screwing up NAT? I can post the ngrep if that still is required.
serctl ul show
.../Record... ...Record(0xb613ed34)... domain: 'location' aor : 'user1' ~~~Contact(0xb613edc4)~~~ domain : 'location' aor : 'user1' Contact : 'sip:user1@60.234.198.XXX:5061' Expires : 1681 q : Call-ID : '47041BCBF01640CBABEDD8D1385DF9D3@domain.com' CSeq : 27061 replic : 0 User-Agent: 'X-Lite release 1103m' received : '' State : CS_SYNC Flags : 0 next : (nil) prev : (nil) ~~~/Contact~~~~ .../Record... ...Record(0xb6140f10)... domain: 'location' aor : 'beattiek' ~~~Contact(0xb613eb8c)~~~ domain : 'location' aor : 'user2' Contact : 'sip:user2@192.168.0.11:5060' Expires : 3565 q : Call-ID : 'ea8b8415-fa111ada@192.168.0.11' CSeq : 2 replic : 0 User-Agent: 'Sipura/SPA2000-2.0.13(g)' received : 'sip:60.234.198.xxx:1025' State : CS_SYNC Flags : 1 next : (nil) prev : (nil) Regards Cameron <snip> ----- Original Message ----- From: Java Rockx To: Cameron Beattie Cc: serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 11:12 PM Subject: Re: [Serusers] SER & Mediaproxy: XLite - Audio OK, Sipura - No audio Cameron, Can you post an complete call trace using ngrep or post a pcap file on port 5060 using tcpdump? Regards, Paul <snip>
ngrep output (some domains and IP addresses masked). Quite long I'm sorry as I didn't know what I could leave out.
U 60.234.198.XXX:5061 -> 147.202.44.XXX:5060 INVITE sip:beattiek@beta.mydomain.co.nz SIP/2.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport;branch=z9hG4bK2A25B1602B7746B78F55E53C0FFF9 47B..From: Cameron's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz..Contact: < sip:beattiec@60.234.198.XXX:5061>..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55815 INVITE..Max-Forwards: 70..Cont ent-Type: application/sdp..User-Agent: X-Lite release 1103m..Content-Length: 301....v=0..o=beattiec 50320967 50320997 IN IP4 60.234.198.2 40..s=X-Lite..c=IN IP4 60.234.198.XXX..t=0 0..m=audio 8000 RTP/AVP 0 8 3 98 97 101..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpmap: 3 gsm/8000..a=rtpmap:98 iLBC/8000..a=rtpmap:97 speex/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. # U 147.202.44.XXX:5060 -> 60.234.198.XXX:5061 SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bK2A25B1602B7746B78F55E53C0FFF947B ..From: Cameron's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz;tag=b27e1a1d33 761e85846fc98f5f3a7e58.d456..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55815 INVITE..Proxy-Authenticate: Digest r ealm="beta.mydomain.co.nz", nonce="426571a2da657e0d51cf5b22e55325e822f608b5"..Server: Sip EXpress router (0.9.1 (i386/linux))..Content- Length: 0..Warning: 392 147.202.44.XXX:5060 "Noisy feedback tells: pid=4042 req_src_ip=60.234.198.XXX req_src_port=5061 in_uri=sip:beatt iek@beta.mydomain.co.nz out_uri=sip:beattiek@192.168.0.11:5060 via_cnt==1".... # U 60.234.198.XXX:5061 -> 147.202.44.XXX:5060 ACK sip:beattiek@beta.mydomain.co.nz SIP/2.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport;branch=z9hG4bK2A25B1602B7746B78F55E53C0FFF947B ..From: Cameron's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz;tag=b27e1a1d33 761e85846fc98f5f3a7e58.d456..Contact: sip:beattiec@60.234.198.XXX:5061..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSe q: 55815 ACK..Max-Forwards: 70..Content-Length: 0.... # U 60.234.198.XXX:5061 -> 147.202.44.XXX:5060 INVITE sip:beattiek@beta.mydomain.co.nz SIP/2.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport;branch=z9hG4bK93B046E9850C4934BB664F0C934F5 5ED..From: Cameron's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz..Contact: < sip:beattiec@60.234.198.XXX:5061>..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 INVITE..Proxy-Authorization: D igest username="beattiec",realm="beta.mydomain.co.nz",nonce="426571a2da657e0d51cf5b22e55325e822f608b5",response="c35cefd9340a99971c6169 cd5c5edb76",uri="sip:beattiek@beta.mydomain.co.nz"..Max-Forwards: 70..Content-Type: application/sdp..User-Agent: X-Lite release 1103m.. Content-Length: 301....v=0..o=beattiec 50320967 50320997 IN IP4 60.234.198.XXX..s=X-Lite..c=IN IP4 60.234.198.XXX..t=0 0..m=audio 8000 RT P/AVP 0 8 3 98 97 101..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpmap:3 gsm/8000..a=rtpmap:98 iLBC/8000..a=rtpmap:97 speex/8000..a= rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. # U 147.202.44.XXX:5060 -> 60.234.198.XXX:5061 SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bK93B046E9850C4934BB664F0 C934F55ED..From: Cameron's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz..Call -ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 INVITE..Server: Sip EXpress router (0.9.1 (i386/linux))..Content-Leng th: 0..Warning: 392 147.202.44.XXX:5060 "Noisy feedback tells: pid=4041 req_src_ip=60.234.198.XXX req_src_port=5061 in_uri=sip:beattiek@ beta.mydomain.co.nz out_uri=sip:beattiek@192.168.0.11:5060 via_cnt==1".... # U 147.202.44.XXX:5060 -> 60.234.198.XXX:1025 INVITE sip:beattiek@192.168.0.11:5060 SIP/2.0..Record-Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Via: SIP/2.0/UDP 147.202.44.XXX;b ranch=z9hG4bK455.9b4864b7.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bK93B046E9850C4934BB664F0C934F55ED..From: Camero n's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz..Contact: <sip:beattiec@60.2 34.198.XXX:5061>..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 INVITE..Max-Forwards: 16..Content-Type: applica tion/sdp..User-Agent: X-Lite release 1103m..Content-Length: 297....v=0..o=beattiec 50320967 50320997 IN IP4 60.234.198.XXX..s=X-Lite..c=I N IP4 127.0.0.1..t=0 0..m=audio 35042 RTP/AVP 0 8 3 98 97 101..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpmap:3 gsm/8000..a=rtpmap: 98 iLBC/8000..a=rtpmap:97 speex/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15.. # U 60.234.198.XXX:1025 -> 147.202.44.XXX:5060 SIP/2.0 100 Trying..To: sip:beattiek@beta.mydomain.co.nz..From: Cameron's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411 316..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 INVITE..Via: SIP/2.0/UDP 147.202.44.XXX;branch=z9hG4bK455.9b 4864b7.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bK93B046E9850C4934BB664F0C934F55ED..Record-Route: <sip:147.202.44.1 40;ftag=502411316;lr=on>..Server: Sipura/SPA2000-2.0.13(g)..Content-Length: 0.... # U 60.234.198.XXX:1025 -> 147.202.44.XXX:5060 SIP/2.0 180 Ringing..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..From: Cameron's laptop <sip:beattiec@beta.mydomain .co.nz:5061>;tag=502411316..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 INVITE..Via: SIP/2.0/UDP 147.202.44. 140;branch=z9hG4bK455.9b4864b7.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bK93B046E9850C4934BB664F0C934F55ED..Record- Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Server: Sipura/SPA2000-2.0.13(g)..Content-Length: 0.... # U 147.202.44.XXX:5060 -> 60.234.198.XXX:5061 SIP/2.0 180 Ringing..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..From: Cameron's laptop <sip:beattiec@beta.mydomain .co.nz:5061>;tag=502411316..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 INVITE..Via: SIP/2.0/UDP 60.234.198. 240:5061;rport=5061;branch=z9hG4bK93B046E9850C4934BB664F0C934F55ED..Record-Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Server: Sipu ra/SPA2000-2.0.13(g)..Content-Length: 0.... #### U 60.234.198.XXX:1025 -> 147.202.44.XXX:5060 SIP/2.0 200 OK..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..From: Cameron's laptop <sip:beattiec@beta.mydomain.co. nz:5061>;tag=502411316..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 INVITE..Via: SIP/2.0/UDP 147.202.44.XXX;b ranch=z9hG4bK455.9b4864b7.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bK93B046E9850C4934BB664F0C934F55ED..Record-Route : sip:147.202.44.XXX;ftag=502411316;lr=on..Contact: Cameron's sipura 2000 sip:beattiek@192.168.0.11:5060..Server: Sipura/SPA2000-2.0. 13(g)..Content-Length: 233..Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER..Supported: x-sipura..Content-Type: application /sdp....v=0..o=- 452560 452560 IN IP4 192.168.0.11..s=-..c=IN IP4 192.168.0.11..t=0 0..m=audio 16400 RTP/AVP 0 100 101..a=rtpmap:0 PCMU/8 000..a=rtpmap:100 NSE/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15..a=ptime:30..a=sendrecv.. # U 147.202.44.XXX:5060 -> 60.234.198.XXX:5061 SIP/2.0 200 OK..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..From: Cameron's laptop <sip:beattiec@beta.mydomain.co. nz:5061>;tag=502411316..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 INVITE..Via: SIP/2.0/UDP 60.234.198.XXX:5 061;rport=5061;branch=z9hG4bK93B046E9850C4934BB664F0C934F55ED..Record-Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Contact: Cameron' s sipura 2000 sip:beattiek@60.234.198.XXX:1025..Server: Sipura/SPA2000-2.0.13(g)..Content-Length: 230..Allow: ACK, BYE, CANCEL, INFO, I NVITE, NOTIFY, OPTIONS, REFER..Supported: x-sipura..Content-Type: application/sdp....v=0..o=- 452560 452560 IN IP4 192.168.0.11..s=-..c=I N IP4 127.0.0.1..t=0 0..m=audio 35042 RTP/AVP 0 100 101..a=rtpmap:0 PCMU/8000..a=rtpmap:100 NSE/8000..a=rtpmap:101 telephone-event/8000.. a=fmtp:101 0-15..a=ptime:30..a=sendrecv.. # U 60.234.198.XXX:5061 -> 147.202.44.XXX:5060 ACK sip:beattiek@60.234.198.XXX:1025 SIP/2.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport;branch=z9hG4bK4A3EF9D8A53446F39AE2685FE004FCC2.. From: Cameron's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c 6d2ei0..Contact: sip:beattiec@60.234.198.XXX:5061..Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Call-ID: E64C4B2D-C0F1-4EA5-845E-5 C30C241402C@192.168.0.15..CSeq: 55816 ACK..Max-Forwards: 70..Content-Length: 0.... # U 147.202.44.XXX:5060 -> 60.234.198.XXX:1025 ACK sip:beattiek@60.234.198.XXX:1025 SIP/2.0..Record-Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Via: SIP/2.0/UDP 147.202.44.XXX;br anch=0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bK4A3EF9D8A53446F39AE2685FE004FCC2..From: Cameron's laptop <sip:beatt iec@beta.mydomain.co.nz:5061>;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..Contact: <sip:beattiec@60 .234.198.XXX:5061>..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 ACK..Max-Forwards: 16..Content-Length: 0.... ## U 60.234.198.XXX:1025 -> 147.202.44.XXX:5060 SIP/2.0 200 OK..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..From: Cameron's laptop <sip:beattiec@beta.mydomain.co. nz:5061>;tag=502411316..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 INVITE..Via: SIP/2.0/UDP 147.202.44.XXX;b ranch=z9hG4bK455.9b4864b7.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bK93B046E9850C4934BB664F0C934F55ED..Record-Route : sip:147.202.44.XXX;ftag=502411316;lr=on..Contact: Cameron's sipura 2000 sip:beattiek@192.168.0.11:5060..Server: Sipura/SPA2000-2.0. 13(g)..Content-Length: 233..Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER..Supported: x-sipura..Content-Type: application /sdp....v=0..o=- 452560 452560 IN IP4 192.168.0.11..s=-..c=IN IP4 192.168.0.11..t=0 0..m=audio 16400 RTP/AVP 0 100 101..a=rtpmap:0 PCMU/8 000..a=rtpmap:100 NSE/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15..a=ptime:30..a=sendrecv.. # U 147.202.44.XXX:5060 -> 60.234.198.XXX:5061 SIP/2.0 200 OK..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..From: Cameron's laptop <sip:beattiec@beta.mydomain.co. nz:5061>;tag=502411316..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 INVITE..Via: SIP/2.0/UDP 60.234.198.XXX:5 061;rport=5061;branch=z9hG4bK93B046E9850C4934BB664F0C934F55ED..Record-Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Contact: Cameron' s sipura 2000 sip:beattiek@60.234.198.XXX:1025..Server: Sipura/SPA2000-2.0.13(g)..Content-Length: 230..Allow: ACK, BYE, CANCEL, INFO, I NVITE, NOTIFY, OPTIONS, REFER..Supported: x-sipura..Content-Type: application/sdp....v=0..o=- 452560 452560 IN IP4 192.168.0.11..s=-..c=I N IP4 127.0.0.1..t=0 0..m=audio 35042 RTP/AVP 0 100 101..a=rtpmap:0 PCMU/8000..a=rtpmap:100 NSE/8000..a=rtpmap:101 telephone-event/8000.. a=fmtp:101 0-15..a=ptime:30..a=sendrecv.. # U 60.234.198.XXX:5061 -> 147.202.44.XXX:5060 ACK sip:beattiek@60.234.198.XXX:1025 SIP/2.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport;branch=z9hG4bK4A3EF9D8A53446F39AE2685FE004FCC2.. From: Cameron's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c 6d2ei0..Contact: sip:beattiec@60.234.198.XXX:5061..Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Call-ID: E64C4B2D-C0F1-4EA5-845E-5 C30C241402C@192.168.0.15..CSeq: 55816 ACK..Max-Forwards: 70..Content-Length: 0.... # U 147.202.44.XXX:5060 -> 60.234.198.XXX:1025 ACK sip:beattiek@60.234.198.XXX:1025 SIP/2.0..Record-Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Via: SIP/2.0/UDP 147.202.44.XXX;br anch=0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bK4A3EF9D8A53446F39AE2685FE004FCC2..From: Cameron's laptop <sip:beatt iec@beta.mydomain.co.nz:5061>;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..Contact: <sip:beattiec@60 .234.198.XXX:5061>..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55816 ACK..Max-Forwards: 16..Content-Length: 0.... # U 60.234.198.XXX:5061 -> 147.202.44.XXX:5060 BYE sip:beattiek@60.234.198.XXX:1025 SIP/2.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport;branch=z9hG4bKD3B4E65CB8F84F6E839D5B7CAA9012D0.. From: Cameron's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c 6d2ei0..Contact: sip:beattiec@60.234.198.XXX:5061..Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Call-ID: E64C4B2D-C0F1-4EA5-845E-5 C30C241402C@192.168.0.15..CSeq: 55817 BYE..Max-Forwards: 70..User-Agent: X-Lite release 1103m..Content-Length: 0.... # U 147.202.44.XXX:5060 -> 60.234.198.XXX:1025 BYE sip:beattiek@60.234.198.XXX:1025 SIP/2.0..Record-Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Via: SIP/2.0/UDP 147.202.44.XXX;br anch=z9hG4bK555.c994b965.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bKD3B4E65CB8F84F6E839D5B7CAA9012D0..From: Cameron 's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..Conta ct: sip:beattiec@60.234.198.XXX:5061..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55817 BYE..Max-Forwards: 16..Us er-Agent: X-Lite release 1103m..Content-Length: 0.... # U 147.202.44.XXX:5060 -> 60.234.198.XXX:1025 BYE sip:beattiek@60.234.198.XXX:1025 SIP/2.0..Record-Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Via: SIP/2.0/UDP 147.202.44.XXX;br anch=z9hG4bK555.c994b965.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bKD3B4E65CB8F84F6E839D5B7CAA9012D0..From: Cameron 's laptop sip:beattiec@beta.mydomain.co.nz:5061;tag=502411316..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..Conta ct: sip:beattiec@60.234.198.XXX:5061..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55817 BYE..Max-Forwards: 16..Us er-Agent: X-Lite release 1103m..Content-Length: 0.... # U 60.234.198.XXX:1025 -> 147.202.44.XXX:5060 SIP/2.0 200 OK..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..From: Cameron's laptop <sip:beattiec@beta.mydomain.co. nz:5061>;tag=502411316..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55817 BYE..Via: SIP/2.0/UDP 147.202.44.XXX;bran ch=z9hG4bK555.c994b965.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bKD3B4E65CB8F84F6E839D5B7CAA9012D0..Record-Route: < sip:147.202.44.XXX;ftag=502411316;lr=on>..Server: Sipura/SPA2000-2.0.13(g)..Content-Length: 0.... # U 147.202.44.XXX:5060 -> 60.234.198.XXX:5061 SIP/2.0 200 OK..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..From: Cameron's laptop <sip:beattiec@beta.mydomain.co. nz:5061>;tag=502411316..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55817 BYE..Via: SIP/2.0/UDP 60.234.198.XXX:5061 ;rport=5061;branch=z9hG4bKD3B4E65CB8F84F6E839D5B7CAA9012D0..Record-Route: sip:147.202.44.XXX;ftag=502411316;lr=on..Server: Sipura/SPA20 00-2.0.13(g)..Content-Length: 0.... # U 60.234.198.XXX:1025 -> 147.202.44.XXX:5060 SIP/2.0 200 OK..To: sip:beattiek@beta.mydomain.co.nz;tag=32d520655c6c6d2ei0..From: Cameron's laptop <sip:beattiec@beta.mydomain.co. nz:5061>;tag=502411316..Call-ID: E64C4B2D-C0F1-4EA5-845E-5C30C241402C@192.168.0.15..CSeq: 55817 BYE..Via: SIP/2.0/UDP 147.202.44.XXX;bran ch=z9hG4bK555.c994b965.0..Via: SIP/2.0/UDP 60.234.198.XXX:5061;rport=5061;branch=z9hG4bKD3B4E65CB8F84F6E839D5B7CAA9012D0..Record-Route: < sip:147.202.44.XXX;ftag=502411316;lr=on>..Server: Sipura/SPA2000-2.0.13(g)..Content-Length: 0.... ##########exit 45 received, 0 dropped
----- Original Message ----- From: Java Rockx To: Cameron Beattie Cc: serusers@lists.iptel.org Sent: Wednesday, April 20, 2005 7:38 AM Subject: Re: [Serusers] SER & Mediaproxy: XLite - Audio OK, Sipura - No audio
Yes, the ngrep will still help.
Regards, Paul
On 4/19/05, Cameron Beattie kjcsb@orcon.net.nz wrote: Thanks for your replies. Some other things I've noticed: - Contact: public IP for X-Lite and private for Sipura - Received: blank for X-Lite and public IP with port of 1025 for Sipura - CallID: SIP proxy domain name for X-Lite and private IP for Sipura
Why are these set differently for the different clients? I'm guessing that it's the Contact record that is screwing up NAT? I can post the ngrep if that still is required.
serctl ul show ~~~/Contact~~~~ .../Record... ...Record(0xb613ed34)... domain: 'location' aor : 'user1' ~~~Contact(0xb613edc4)~~~ domain : 'location' aor : 'user1' Contact : 'sip:user1@60.234.198.XXX:5061' Expires : 1681 q : Call-ID : '47041BCBF01640CBABEDD8D1385DF9D3@domain.com' CSeq : 27061 replic : 0 User-Agent: 'X-Lite release 1103m' received : '' State : CS_SYNC Flags : 0 next : (nil) prev : (nil) ~~~/Contact~~~~ .../Record... ...Record(0xb6140f10)... domain: 'location' aor : 'beattiek' ~~~Contact(0xb613eb8c)~~~ domain : 'location' aor : 'user2' Contact : 'sip:user2@192.168.0.11:5060' Expires : 3565 q : Call-ID : 'ea8b8415-fa111ada@192.168.0.11 ' CSeq : 2 replic : 0 User-Agent: 'Sipura/SPA2000-2.0.13(g)' received : 'sip:60.234.198.xxx:1025' State : CS_SYNC Flags : 1 next : (nil) prev : (nil)
Regards
Cameron <snip> ----- Original Message ----- From: Java Rockx To: Cameron Beattie Cc: serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 11:12 PM Subject: Re: [Serusers] SER & Mediaproxy: XLite - Audio OK, Sipura - No audio
Cameron,
Can you post an complete call trace using ngrep or post a pcap file on port 5060 using tcpdump?
Regards, Paul <snip>
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Cameron,
The problem is that the c= field in the SDP payload is always pointing to 127.0.0.1 http://127.0.0.1 (aka, your loopback interface). This is not going to work since neither Sipura or X-lite client can connect to your loopback interface.
More specifically, the INVITE message that is sent from the Sipura to the SER proxy is then rewritten and then relayed to the X-lite SIP UA. This relayed INVITE has the incorrect c= field in the SDP.
Likewise, the 200OK that X-lite replies with is then rewritten by SER and relayed to the Sipura UA. This 200OK also has a c= of 127.0.0.1http://127.0.0.1
I suspect that your call to use_media_proxy() is correct, but media proxy is running on the wrong interface.
If you look at the onsip.org http://onsip.org documentation you will find a mediaproxy init.d start script in the appendix. In this start script you will see the following line:
PROXY_OPTIONS="--ip=71.16.1.15 http://71.16.1.15 --listen=127.0.0.1http://127.0.0.1 "
The --ip option must be an IP that is available to all SIP clients (NATed an non-NATed). Therefore you should specify a public ip address. This then is the ip that will be used in the c= field in the SDP payload. The --listen parameter can be 127.0.0.1 http://127.0.0.1 if you are running mediaproxy on your SIP router. If not, then you will need to change this as well.
NOTE: If you're mediaproxy is behind an ALG enabled router, such as a Cisco 3600, then the router will rewrite the RFC1918 IPs with the public ones, so in this case you would use the --ip option as an RFC1918 address.
Regards, Paul
Thanks very much.
I have altered the mediaproxy setup and that now works (what a relief). However what I did was not quite what you suggested.
When I updated the mediaproxy init.d script and tried to start mediaproxy I got the message "no such option: --ip" which I was a little surprised about. I am running mediaproxy 1.3.0. So I did a bit more reading and updated the mediaproxy.ini script instead adding the line proxyIP = XXX.XXX.XXX.XXX. Anyway I don't know if that's a change in the latest version of mediaproxy or if I did something stupid.
Nevertheless I should have RTFM'd from the start! Once again many many thanks for you help.
Regards
Cameron ----- Original Message ----- From: Java Rockx To: Cameron Beattie Cc: serusers@lists.iptel.org Sent: Wednesday, April 20, 2005 12:38 PM Subject: Re: [Serusers] SER & Mediaproxy: XLite - Audio OK, Sipura - No audio
Cameron,
The problem is that the c= field in the SDP payload is always pointing to 127.0.0.1 (aka, your loopback interface). This is not going to work since neither Sipura or X-lite client can connect to your loopback interface.
More specifically, the INVITE message that is sent from the Sipura to the SER proxy is then rewritten and then relayed to the X-lite SIP UA. This relayed INVITE has the incorrect c= field in the SDP.
Likewise, the 200OK that X-lite replies with is then rewritten by SER and relayed to the Sipura UA. This 200OK also has a c= of 127.0.0.1
I suspect that your call to use_media_proxy() is correct, but media proxy is running on the wrong interface.
If you look at the onsip.org documentation you will find a mediaproxy init.d start script in the appendix. In this start script you will see the following line:
PROXY_OPTIONS="--ip=71.16.1.15 --listen=127.0.0.1"
The --ip option must be an IP that is available to all SIP clients (NATed an non-NATed). Therefore you should specify a public ip address. This then is the ip that will be used in the c= field in the SDP payload. The --listen parameter can be 127.0.0.1 if you are running mediaproxy on your SIP router. If not, then you will need to change this as well.
NOTE: If you're mediaproxy is behind an ALG enabled router, such as a Cisco 3600, then the router will rewrite the RFC1918 IPs with the public ones, so in this case you would use the --ip option as an RFC1918 address.
Regards, Paul
------------------------------------------------------------------------------
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
It's the same difference. The --ip was in version < 1.3.0 and since you're using 1.3.0 all the options are in the .ini file.
So you're good.
Regards, Paul
On 4/19/05, Cameron Beattie kjcsb@orcon.net.nz wrote:
Thanks very much. I have altered the mediaproxy setup and that now works (what a relief). However what I did was not quite what you suggested. When I updated the mediaproxy init.d script and tried to start mediaproxy I got the message "no such option: --ip" which I was a little surprised about. I am running mediaproxy 1.3.0. So I did a bit more reading and updated the mediaproxy.ini script instead adding the line proxyIP = XXX.XXX.XXX.XXX. Anyway I don't know if that's a change in the latest version of mediaproxy or if I did something stupid. Nevertheless I should have RTFM'd from the start! Once again many many thanks for you help. Regards Cameron
----- Original Message ----- *From:* Java Rockx javarockx@gmail.com *To:* Cameron Beattie ext_news@appsfarm.com *Cc:* serusers@lists.iptel.org *Sent:* Wednesday, April 20, 2005 12:38 PM *Subject:* Re: [Serusers] SER & Mediaproxy: XLite - Audio OK, Sipura - No audio
Cameron,
The problem is that the c= field in the SDP payload is always pointing to 127.0.0.1 http://127.0.0.1 (aka, your loopback interface). This is not going to work since neither Sipura or X-lite client can connect to your loopback interface.
More specifically, the INVITE message that is sent from the Sipura to the SER proxy is then rewritten and then relayed to the X-lite SIP UA. This relayed INVITE has the incorrect c= field in the SDP.
Likewise, the 200OK that X-lite replies with is then rewritten by SER and relayed to the Sipura UA. This 200OK also has a c= of 127.0.0.1http://127.0.0.1
I suspect that your call to use_media_proxy() is correct, but media proxy is running on the wrong interface.
If you look at the onsip.org http://onsip.org documentation you will find a mediaproxy init.d start script in the appendix. In this start script you will see the following line:
PROXY_OPTIONS="--ip=71.16.1.15 http://71.16.1.15 --listen=127.0.0.1http://127.0.0.1 "
The --ip option must be an IP that is available to all SIP clients (NATed an non-NATed). Therefore you should specify a public ip address. This then is the ip that will be used in the c= field in the SDP payload. The --listen parameter can be 127.0.0.1 http://127.0.0.1 if you are running mediaproxy on your SIP router. If not, then you will need to change this as well.
NOTE: If you're mediaproxy is behind an ALG enabled router, such as a Cisco 3600, then the router will rewrite the RFC1918 IPs with the public ones, so in this case you would use the --ip option as an RFC1918 address.
Regards, Paul
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Cameron Beattie -
Greger V. Teigre -
Java Rockx