[Serusers] Revisted Error: force_rtp_proxy2: can't extractbodyfrom the message

[Java Rockx]

The only reason I removed the "if else" in favor of two (2) "if" statments was nothing more than
code simplification. As I recall I was having to call fix_nated_contact in both branches anyhow.

Regards,
Paul

--- "Greger V. Teigre" <greger at teigre.com> wrote:

> 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:
>
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/nathelper.cfg?rev=1.1.2.1&content-type=text/vnd.viewcvs-markup
> 
> 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:
> > 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" <greger at teigre.com> wrote:
> >
> >> Paul,
> >> Thanks for posting your resulting config after so many hours of
> >> testing! I did a diff and can see that you have done several
> >> (smaller) changes. But what did the trick? (i.e. for Route problem)
> >> g-)
> >>
> >> Java Rockx wrote:
> >>> 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 at 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:
> >>>>>
> >>>>> 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
> 
=== message truncated ===



		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com