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

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