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

Good to get an authoriative answer on this. I think I should allocate

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

list, but anyway a bug report should be submitted to Grandstream. This

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(a)yahoo.com> >> To: "Greger V. Teigre" <greger(a)teigre.com>om>; "ser users" >> <serusers(a)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 >>>

>>> 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 >>>

>>> 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.