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(a)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(a)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(a)192.168.0.83. CSeq: 21752 ACK. User-Agent: Grandstream BT100 1.0.5.16. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. . --- "Greger V. Teigre" &lt;greger(a)teigre.com&gt; wrote: === message truncated === __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

No, ser does not change Record-Route to Route header field, user agents are supposed to do it. SER does only two things: 1) 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" &lt;javarockx(a)yahoo.com&gt; > To: "Greger V. Teigre" &lt;greger(a)teigre.com&gt;om>; "ser users" > &lt;serusers(a)lists.iptel.org&gt; 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(a)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(a)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(a)192.168.0.83. >> CSeq: 21752 ACK. >> User-Agent: Grandstream BT100 1.0.5.16. >> Max-Forwards: 16. >> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. >> . >> >> >> --- "Greger V. Teigre" &lt;greger(a)teigre.com&gt; wrote: >> >>> A few comments/questions after having looked at your config file: >>> - You are using 1.0.5.11 firmware on your Grandstream. 1.0.5.16 is >>> the latest and a lot of things have happened since 11. I would >>> suggest you upgrade the firmware before you spend more time on it. >>> - The SIP conversation you sent earlier shows a conversation >>> without using >>> STUN. In later messages you write about setting outbound and then >>> stun. Have you tried setting outbound, but not stun? Any >>> difference in Route? >>> - From 1.0.5.7, Grandstream started to send stun-detected ip and >>> port when >>> symmetric NAT was found. My experience is that if stun is set on >>> such a phone, you will not be able to catch the REGISTER with >>> nat_uac_test("3"), but need to add the "rport different from src" >>> test (16) found in the cvs (and then use ("19")). If you contrary >>> to what I have seen are able to catch the Grandstream as behind >>> NAT with nat_uac_test("3"), I would love to >>> see the trace of that conversation... >>> - I don't have much experience with proxying, so this is a shot in >>> the dark: >>> It looks like the ACKs get rewritten by ser because the ACK is >>> part of a nat'ed conversation. Could fix_nated_contact() be doing >>> this? I haven't had time to check the code yet. What would >>> happen if you added a search on >>> Route: >>> >>> if (method=="REGISTER" || (!search("^Record-Route:")) || >>> (!search("^Route:"))) ) { >>> >>> fix_nated_contact(); >>> >>> The way I read the mesage from the Sonus guys, the ACK with Route >>> in it should not be touched. Or am I wrong? However, I'm pretty >>> sure that such a >>> exception to fix_nated_contact is not common... >>> >>> Well, my 2c worth... >>> g-) >>> >>> ----- Original Message ----- >>> From: "Java Rockx" &lt;javarockx(a)yahoo.com&gt; >>> To: "Greger V. Teigre" &lt;greger(a)teigre.com&gt;om>; "ser users" >>> &lt;serusers(a)lists.iptel.org&gt; >>> Sent: Thursday, November 18, 2004 05:55 PM >>> Subject: Re: [Serusers] Revisted Error: force_rtp_proxy2: can't >>> extract bodyfrom the message >>> >>> >>>> Thanks Greger! >>>> >>>> Yes, I'd love another set of eyes. Attached is my entire ser.cfg >>>> (bogus IPs of course). >>>> >>>> Regards Paul. >>>> >>>> >>>> >>>> --- "Greger V. Teigre" &lt;greger(a)teigre.com&gt; wrote: >>>> >>>>> Paul, >>>>> I'm not sure if this went on the list? I get digests... >>>>> >>>>> Thanks for your answer on content-length, I'll try it out. I >>>>> went back >>>>> to >>>>> your original message on ACK and Route. I cannot understand how >>>>> ser should >>>>> process an ACK with STUN differently from without. If this >>>>> assumption is >>>>> correct, you would probably have a different execution path in >>>>> your ser.cfg >>>>> dependent on STUN or not. It could have something to do with >>>>> what I wrote >>>>> in my last email with regards to the error in Grandstream when >>>>> behind symmetric NAT. I use nat_uac_test("19") to catch >>>>> Grandstreams with firmware >>>>> 10.0.5.16 as the contact and via will be public_ip:portfromstun >>>>> while the >>>>> request comes from public_ip:portfromsiprequest. >>>>> >>>>> I'm not confident I can help here as this is at the edge of my >>>>> knowledge >>>>> of >>>>> the topic, but if you want an external look at your config, I'll >>>>> be happy >>>>> to >>>>> have a look at it. >>>>> g-) >>>>> >>>>> >>>>> Java Rockx wrote: >>>>>> I am using >>>>>> >>>>>> if(!(search("^Content-Length:\ 0")) {} >>>>>> >>>>>> in my ser.cfg and it seems to have eliminated all errors. >>>>>> Honestly, I >>>>>> still have yet to test this with inbound calls from our PSTN >>>>>> provider's Sonus equipment. >>>>>> >>>>>> My bigger issue is why would SER add "Route:" headers correctly >>>>>> to ACK messages that flow from my SER proxy to their Sonus box >>>>>> only when >>>>>> my IP phone is configured to use STUN? >>>>>> >>>>>> I am using nathelper and rtpproxy and everthing seems to work >>>>>> just fine inside or outside of our firewall and no IP phones >>>>>> seem to need STUN for SIP messages and RTP to play nice with >>>>>> our firewall or client's firewalls as as far as I can tell my >>>>>> ser.cfg is good. >>>>>> >>>>>> So IMHO one of two things is happening; >>>>>> >>>>>> * I have an error that I'm not aware of in my ser.cfg related to >>>>>> NATed versus non-NATed UACs * nathelper/rtpproxy is not usable >>>>>> when SER is interacting with other SIP proxies and STUN must be >>>>>> used. >>>>>> >>>>>> Has anyone ever gotten SER to talk with other SIP proxies using >>>>>> NATed >>>>>> clients? >>>>>> >>>>>> Regards, >>>>>> Paul >>>>>> >>>>>> --- "Greger V. Teigre" &lt;greger(a)teigre.com&gt; wrote: >>>>>> >>>>>>> Hi, >>>>>>> I've been following this thread as I have experienced the same >>>>>>> problems myself. When I get incoming calls (both from Cisco >>>>>>> IP-PSTN >>>>>>> gateway and from other SIP phones) to a Grandstream behind >>>>>>> symmetric >>>>>>> NAT, the messages you have noted can be seen in the log when >>>>>>> hanging >>>>>>> up. >>>>>>> >>>>>>> I was not certain as to the conclusion you ended with. Do you >>>>>>> use the filter: >>>>>>> if (!(search("^Content-Length:\ 0")) { >>>>>>> force_rtp_proxy(); >>>>>>> }; >>>>>>> >>>>>>> to avoid the errors? I have been thinking about testing on >>>>>>> method and not call force on BYE and ACK. Have you tried this? >>>>>>> >>>>>>> I also saw your question on RFC compliance and the Sonus >>>>>>> equipment: In order to make Grandstream phones register >>>>>>> properly when using STUN behind symmetric NAT, I had to patch >>>>>>> nathelper with the rport != port of received address check. >>>>>>> (I use 0.8.14 and I guess you already have the patch with the >>>>>>> development version). The reason is >>>>>>> that Grandstream attempts to rewrite the address using STUN >>>>>>> even though it correctly detects a symmetric NAT. I have >>>>>>> seen that this >>>>>>> was introduced in a new firmware not long ago (release notes). >>>>>>> This >>>>>>> pussles me as sources I have seen claims this to be invalid >>>>>>> behavior >>>>>>> (which seems correct to me). >>>>>>> >>>>>>> Best regards, >>>>>>> Greger >>>>>>> >>>>>>> >>>>>>> Java Rockx wrote: >>>>>>>> Hi All. >>>>>>>> >>>>>>>> I've hacked my ser.cfg but can someone comment on why I would >>>>>>>> be recieving a "200 OK" with a >>>>>>>> >>>>>>>> The change I made to my onreply_route is below. The only >>>>>>>> thing I can >>>>>>>> see about these messages versus others is that the CSeq says >>>>>>>> "CSeq: >>>>>>>> {some digits} BYE" with "Content-Length: 0". >>>>>>>> >>>>>>>> So for these messages I'm just not calling force_rtp_proxy(). >>>>>>>> >>>>>>>> I don't know if this is a symptom of my Grandstream BT100 >>>>>>>> only of if >>>>>>>> other ATAs or IP phones do this. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Paul >>>>>>>> >>>>>>>> onreply_route[1] { >>>>>>>> >>>>>>>> >>>>>>>> if (isflagset(2) && status =~ "(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(); >>>>>>>> }; >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> --- Java Rockx &lt;javarockx(a)yahoo.com&gt; wrote: >>>>>>>> >>>>>>>>> Hi all. >>>>>>>>> >>>>>>>>> I've got nathelper and rtpproxy working very well with my >>>>>>>>> firewall. >>>>>>>>> However I do still recieve these messages in my syslog. I am >>>>>>>>> only catching 183 and 2xx errors in my onreply_route so I'm >>>>>>>>> very confused how to prevent these errors. >>>>>>>>> >>>>>>>>> I'm using ser-0.8.99-dev12. Can anyone give me some advise? >>>>>>>>> Cheers, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> NOTE: The SIP message that caused these errors is at the >>>>>>>>> bottom of >>>>>>>>> this message. >>>>>>>>> >>>>>>>>> 0(27011) ERROR: extract_body: message body has length zero >>>>>>>>> 0(27011) ERROR: force_rtp_proxy2: can't extract body from >>>>>>>>> the message 0(27011) ERROR: on_reply processing failed >>>>>>>>> >>>>>>>>> My onreply_route is here: >>> >> === message truncated === >> >> >> >> >> __________________________________ >> Do you Yahoo!? >> The all-new My Yahoo! - Get yours free! >> http://my.yahoo.com >> >> >> >> > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers

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" &lt;greger(a)teigre.com&gt; wrote: === message truncated === __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

Greger, I believe the small change to the onfailure_route[] was the thing that made the difference. Andrei pointed out a small error to me where I was calling fix_nated_contact() for more messages than I should have. (THANKS ANDREI!!!) The other thing that made a **substantial** improvement was the fact that our PSTN gateway provider that uses Sonus equipment as added as an "alias" at the top of the ser.cfg. This caused ser to not include "Route:" headers on ACKs and this was causing the Sonus equipment to drop calls after two minutes. It's funny how such small changes to ser.cfg can have dramatic effects. I'd love to see a complete book published on ser. I'm sure, with the help of the maintainers and serusers participants this could become a reality. I mean this is the best damned SIP router I know of. Commercial solutions such as Sonus are not really a "solution" because they run as much as US$2 million per box and most small companies can't afford "one". And even if you could afford =>one<= you may not be able to afford others for scaling your VoIP platform - so whats the point of attempting VoIP if you can't scale? Our solution is modeled after the Google network whereby: unlimited horizontal scalablity == unlimited cps (calls per second) And this equates to: successful VoIP Company == retired employee If we can indeed do this for our implementation and do it on low end x86 or Opteron boxes (or blade servers), then the sky is the limit. Our engineer whom we acquired from RedHat a few months ago already has a full TCP/IP and UDP socket patch working so we can seperate ser and serweb and scale them independently of each other (over a VPN) since we don't need ser's existing FIFO. SEMS is a whole other beast. We are now working on this using the ivr module with sipums for a carrier-grade voicemail solution. Early indications is that we still have plenty to do in order to get 99.999% reliablity with sems. Our goal is to not have sems run on the same box as ser as we already know this is bad. Voicemail and SIP proxy cannot be the same box if you expect to be a big VoIP provider, IMHO. So our high-level VoIP platform uses the following as independent server farms: MySQL 4.1.7 (farm 1) ser-0.8.99-dev17 (farm 2) serweb on Apache2 farm 3) sems/ivr/sipums (farm 4, still a work in progress) Third party PSTN gateway *** see comment below All servers use Whitebox Linux Respin 1 and our network implementation allows us to completely administer all servers at any remote co-lo site --- even down to remote installation of the operating system. This includes make a change to the master ser.cfg and having it replicate to all ser proxies. Monitoring is a big part of this network architecture and we've only got basic monitoring right now, so this will become a focus of our efforts soon. We also use third parties for providing PSTN access. IMHO, PSTN gateways are much more trouble than their worth. We'd rather rely on multiple third parties for this than to try and do it ourselves. The cost of DSP boards is expensive, especially if you wanted to handle say 50,000 concurrent callers. For this very reason we use companies such as Level 3 and Global Crossing and all we have to do is simply monitor their QoS and route PSTN callers to other PSTN gateways as needed. And this is all at the network level, so ser is totally oblivious to this. Another thing I've love to see is a database whereby VoIP service providers can lookup 10-digit DIDs in a common database (much like a root DNS server) and determine if a callee is a VoIP user and route the SIP call directly from our SIP proxy to their SIP proxy rather than making a SIP->PSTN->SIP call. We have the Chairman of the IPCC deeply invovled in our company and he could get the ball rolling on this, but we don't want to get distracted right now. Anyhow, I've rambled long enough. Regards, Paul Hazlett We'll publish our --- "Greger V. Teigre" &lt;greger(a)teigre.com&gt; wrote: === message truncated === __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

Thanks for the reply. See my inline comments. Regards, Paul --- "Greger V. Teigre" &lt;greger(a)teigre.com&gt; wrote: It's funny you mention this because just this morning we were discussing a router update that RH released that is not in WhiteBox yet. So now we're considering going to to production with RHPW which is only $69 and comes with a free upgrade to REL 4 when available. RHPW is a bit of a backdoor loophole in the RedHat pricing structure. Putting -dev17 into production is a possiblity. This really depends on when ser-0.9 stable gets released. If we can hold back the business until then we'll use stable 0.9 otherwise we're forced to use -dev17 (Which has been very stable in our testing). The reason for this is that we have dependencies on avpops and a few other modules that are not in 0.8.14 Voicemail is a big problem right now. I know I'll make a few Asterisk advocates upset with my next comment - but our perception is our reality :-(. Asterisk is not ready for a carrier-grade implementation. Everyone we've seen and talked to that uses Asterisk has stability issues when you exceed a small to medium size company. We need to provide voicemail for as many as 500,000 users and Asterisk ain't going to do the trick. I'm not suggesting that sems/sipums will work either, but I believe it has a better chance than Asterisk. If sems/sipums ends up not working either then we will be force to purchase carrier-grade voicemail applicances that are SIP aware. :-( serweb is a total band-aide until we create similar functionality in our J2EE web farm. We've stripped out much of what is in serweb and only give users access to things like their personal phonebook, speed dialing, etc. I agree. Possibly. Voicemail is still my single biggest problem. And the only solutions I know of are Asterisk and sems. Do you know of any others (open source)? As for helping the ser community - I really think the single biggest way would be to product a real book - kind of like a FSF GDB or GCC book with detailed explainations of "if ser.cfg option does this" and "if you need to provide xxxx then you must have yyyy in ser.cfg" and expert hints and things to avoid. I'm talking about a real book here not an abbrievated cookbook or mini-howto's. Also, a paid consultancy like the ones that Orion Server or JBoss have would be awesome. I've read in the serusers list of people offering to pay someone to fix their ser.cfg. That all said - I'm not an author and I know I'm not an authoritative knowledgebase on ser so I'm sure I'm not the one to do this, although I'd love to help. The sad part is that I can only imagine how busy Daniel, Jan, Jiri, Andrei and company are so I'd say nobody should expect much involvement from them, other than editing and probably most ser users aren't saavy enough to read ser source code to find out exactly how the product works. And (documentation == success) of any product since lack of documentation will lead to fewer deployments. Just my US$0.02 worth === message truncated === __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

A small follow-up comment to your config file. You have the following in onreply_route in the config file you just sent: if (isflagset(2) && status =~ "(180)|(183)|2[0-9][0-9]") { if (!search("^Content-Length:\ 0")) { force_rtp_proxy(); }; }; if (nat_uac_test("1")) { fix_nated_contact(); }; Andrei pointed out that you should not do fix_nated_contact() within the first if-clause. To my surprise, I found that one of my config files had exactly the same error! After searching a bit, I found the source: The example file in the repository:

I think many people use that config as a starting point. If it's wrong, maybe it should be corrected?! Also, in that config you find that the nat_uac_test() has 'else if' in front of it, you also had it in your previous file. Any reason you removed the else? g-) Java Rockx wrote: