[Serusers] Revisted Error: force_rtp_proxy2: can'textractbodyfrom the message

Sun Nov 21 02:11:11 CET 2004

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 at 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 at 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 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 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 at yahoo.com>
> > >> To: "Greger V. Teigre" <greger at teigre.com>; "ser users"
> > >> <serusers at 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 at sip.mycompany.com;user=phone>;tag=069c9797.
> > >>> From: "Paul (1002)"
> > >>> <sip:9990010001 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
> > >>> Call-ID: e37c04be3e50ea72 at 192.168.0.83.
> > >>> CSeq: 21752 INVITE.
> > >>> Contact: sip:4075551212 at 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 at 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 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
> > >>> To: <sip:14075551212 at sip.mycompany.com;user=phone>;tag=069c9797.
> > >>> Contact: <sip:9990010001 at 192.168.0.83;user=phone>.
> > >>> Call-ID: e37c04be3e50ea72 at 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 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
> > >>> To: <sip:14075551212 at sip.mycompany.com;user=phone>;tag=069c9797.
> > >>> Contact: <sip:9990010001 at 100.10.10.10:5060;user=phone>.
> > >>> Call-ID: e37c04be3e50ea72 at 192.168.0.83.
> 
=== message truncated ===

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