RE: [Serusers] Revisted Error: force_rtp_proxy2: can'textractbodyfrom the message - sr-users

21 Nov 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 &lt;shah(a)zynergy.com&gt; 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" &lt;greger(a)teigre.com&gt; 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" &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. 
  === message truncated
===

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