The script I posted will not work with ser-0.8.14
You **must** check out ser-0.8.99-dev17 from Berlios CVS because this ser.cfg uses many features of ser that are only available in the unstable version.
Regards, Paul
--- S Shah shah@zynergy.com wrote:
Paul, I wanted to try your ser.cfg file but I'm getting a lot of errors when I try to run SER using that ser.cfg file. I have version 8.14 installed on redhat 9. I don't have the modules: uri_db.so, speeddial.so, options.so. The function fix_nated_register also cannot be found.
What am I missing? Thanks. Sher
-----Original Message----- From: Java Rockx [mailto:javarockx@yahoo.com] Sent: Saturday, November 20, 2004 4:06 PM To: Greger V. Teigre; ser users Subject: Re: [Serusers] Revisted Error: force_rtp_proxy2: can'textractbodyfrom the message
Greger,
I finally got everything working without STUN and without an Outbound Proxy. I an only using rtpproxy/nathelper.
I've tested these settings with the following SIP Phones/ATAs
Sipura UTstarcom iAN-02EX Grandstream ATA486 Grandstream BT100 Cisco ATA186 Cisco 7960G WorldAccxx ATA X-Ten Pro X-Ten Lite
We are very happy with everything now. The only piece of the puzzle that I don't have working yet is sems/sipums for voicemail - but I'm working on that.
Attached is my complete ser.cfg file that is working. Please note that I'm using ser-0.8.99-dev17 for this rather than ser-0.8.14
If anyone finds problems in this ser.cfg then please let me know - but like I said before, things seem very stable right now with -dev17.
Regards, Paul
--- "Greger V. Teigre" greger@teigre.com wrote:
Good to get an authoriative answer on this. I think I should allocate
some
time to read the RFC thoroughly. This leads back to my guess that it could be Paul's outbound proxy setting that fixed the problem. I would think that are some Grandstream people
this
list, but anyway a bug report should be submitted to Grandstream. This
was
a hard bug to track. Paul? g-)
Jan Janak wrote:
No, ser does not change Record-Route to Route header field, user agents are supposed to do it. SER does only two things:
- Adds Record-Route header fields with its own IP address (this is
what record_route function does) 2) Removes the topmost Route header field if it contains its own IP address (according to the IP) and forwards the message to the IP in the next Route header field if any. If there is no other Route header field then the Request-URI would be used.
If there are some Route header fields missing in ACK then this is a bug in the calling user agent, not SER.
Jan.
On 18-11 21:16, Greger V. Teigre wrote:
I believe the changes are done in the rr module, in the loose.c file. RFC3261 defines this (as mentioned by the Sonus guys). I remember vaguely reading something about equivalence between defining outbund proxy on the client and a Route header, but I'm way off stable ground here... However, if I remember correctly, it is probably the outbound proxy and not the stun settings that does the trick. I have seen some discussions on loose routing earlier this fall, maybe a search on loose routing in the archives can turn up some new approaches?
I'm afraid I don't have anything more to contribute here. From all I can see, ser should change the Record-Routes to Route, but doesn't, and I don't understand why. I think we need somebody with a more in-depth understanding of the ser inner workings. g-)
----- Original Message ----- From: "Java Rockx" javarockx@yahoo.com To: "Greger V. Teigre" greger@teigre.com; "ser users" serusers@lists.iptel.org Sent: Thursday, November 18, 2004 08:21 PM Subject: Re: [Serusers] Revisted Error: force_rtp_proxy2: can't extract bodyfrom the message
Greger,
Do you have any idea how SER decides to include a "Route:" versus a "Record-Route:" header? If so, which piece of code in ser would write the second ACK below?
Here is a "200 OK" and two ACKs - The first ACK is good and the second ACK is bad because it should have a "Route:" header referring to the Sonus box.
100.99.99.99.99 is my SER proxy 100.10.10.10 is the public side of my firewall 216.50.50.50 is the ip of the Sonus box
So the ACK from SER to Sonus is incorrect.
Do you think this is worth posing to Jiri, Andrei, and company? All I know is that this ACK is bad when STUN is not used and it is good when STUN is used. I did upgrade my Grandstream, but that didn't help, and I've modified my nat_uac_test to use mode==19 rather than mode==3, but still get the same results.
Regards, Paul
U 2004/11/18 14:13:08.419098 100.99.99.99:5060 -> 100.10.10.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP
192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKa70081ccdd52daf0 .
To: sip:14075551212@sip.mycompany.com;user=phone;tag=069c9797. From: "Paul (1002)" sip:9990010001@sip.mycompany.com;user=phone;tag=92691bb29380c100. Call-ID: e37c04be3e50ea72@192.168.0.83. CSeq: 21752 INVITE. Contact: sip:4075551212@216.50.50.50:5060. Record-Route: sip:216.50.50.50:5060;lr. Record-Route: sip:100.99.99.99;ftag=92691bb29380c100;lr=on. Accept: multipart/mixed, application/sdp, application/isup, application/dtmf, application/dtmf-relay. Allow: OPTIONS, INVITE, CANCEL, ACK, BYE, PRACK, INFO. Supported: timer. Content-Disposition: session;handling=required. Content-Type: application/sdp. Session-Expires: 240;refresher=uas. . v=0. o=Sonus_UAC 18748 26881 IN IP4 216.229.118.76. s=SIP Media Capabilities. c=IN IP4 100.99.99.99. t=0 0. m=audio 35552 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. a=nortpproxy:yes.
# U 2004/11/18 14:13:08.428394 100.10.10.10:5060 -> 100.99.99.99:5060 ACK sip:4075551212@216.50.50.50:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.0.83;branch=z9hG4bKf4bb608e498ec61d. Route: sip:100.99.99.99;ftag=92691bb29380c100;lr=on. Route: sip:216.50.50.50:5060;lr. From: "Paul (1002)" sip:9990010001@sip.mycompany.com;user=phone;tag=92691bb29380c100. To: sip:14075551212@sip.mycompany.com;user=phone;tag=069c9797. Contact: sip:9990010001@192.168.0.83;user=phone. Call-ID: e37c04be3e50ea72@192.168.0.83. CSeq: 21752 ACK. User-Agent: Grandstream BT100 1.0.5.16. Max-Forwards: 70. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. .
# U 2004/11/18 14:13:08.429879 100.99.99.99:5060 -> 216.50.50.50:5060 ACK sip:216.50.50.50:5060;lr SIP/2.0. Via: SIP/2.0/UDP 100.99.99.99;branch=z9hG4bK2b35.552edb80cbf475b9be9ae3f9db23f960.0. Via: SIP/2.0/UDP
192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKf4bb608e498ec61d .
From: "Paul (1002)" sip:9990010001@sip.mycompany.com;user=phone;tag=92691bb29380c100. To: sip:14075551212@sip.mycompany.com;user=phone;tag=069c9797. Contact: sip:9990010001@100.10.10.10:5060;user=phone. Call-ID: e37c04be3e50ea72@192.168.0.83.
=== message truncated ===
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com