>From the log that you previously posted, you are invoking force_rtp_proxy on the INVITE, and the INVITE has no SDP (and there you have your first error log). Then you got a reply and you are trying to invoke force_rtp_proxy with incorrect parameters maybe and there you have the second error. You need to fix your script and properly invoke the rtpproxy functions for INVITE/200ok or 200ok/ACK.
Maybe it's time to upgrade and use rtpproxy_offer/answer functions (see example in README file): http://www.opensips.org/html/docs/modules/devel/rtpproxy.html#id292912 Regards, Ovidiu Sas On Thu, Mar 31, 2011 at 7:11 PM, Leon Li <leon...@aarnet.edu.au> wrote: > Hi Razvan, > > The call was initialled from CUCM (public side), which always does late > offer, so there is no SDP body in the first INVITE. The SDP was created in > the “200 OK” by the Callee (private side). Anyway we can parse this one. > > The function used is force_rtp_proxy() as I am still on v1.6.2. > > Regards, > > Leon > > > > From: users-boun...@lists.opensips.org > [mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea > Sent: Friday, 1 April 2011 12:18 AM > > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] inconsistence nathelper behavior > > > > Hello Leon, > > As you can see, OpenSIPS is unable to parse the SDP body. Please make sure > that your INVITE message has SDP body. If it does and you still have the > problem, a capture of the initial INVITE would be very useful. > There are no debug messages of RTPProxy, only INFOs. Can you please tell me > if the RTPProxy error comes from an rtpproxy_offer function or > rtpproxy_answer? > > Regards, > Razvan > > On 03/30/2011 01:40 AM, Leon Li wrote: > > Hi Razvan, > > > > I’ve turned on DBUG, although not many output in syslog. > > > > Mar 29 22:12:05 /usr/sbin/opensips[9336]: INVITE Received - > RURI=sip:xxxxxxxxxxxxxxxxxxxxxxxxx > > Mar 29 22:12:05 /usr/sbin/opensips[9336]: Alias Found, New > RURI=xxxxxxxxxxxxxxxxxxxx > > Mar 29 22:12:05 /usr/sbin/opensips[9336]: ERROR:nathelper:force_rtp_proxy: > Unable to parse body > > Mar 29 22:12:05 /usr/sbin/opensips[9336]: new branch at > sip:xxxxxx@192.168.1.112:19463;user=phone > > Mar 29 22:12:05 /usr/sbin/opensips[9321]: incoming reply > > Mar 29 22:12:05 /usr/sbin/opensips[9325]: incoming reply > > Mar 29 22:12:07 /usr/sbin/opensips[9323]: incoming reply > > Mar 29 22:12:07 /usr/sbin/opensips[9323]: > ERROR:nathelper:force_rtp_proxy_body: incorrect port 0 in reply from rtp > proxy > > Mar 29 22:12:07 rtpproxy[11501]: INFO:handle_command: lookup request failed: > session 9332ee00-d9215935-5a7d0-22cf9eca@Public IP, tags > 7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;1/1219087299;1 not found > > Mar 29 22:12:07 /usr/sbin/opensips[9323]: ACC: transaction answered: > timestamp=1301436727;method=INVITE;from_tag=7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf9eca@xxxx;code=200;reason=OK > > Mar 29 22:12:07 /usr/sbin/opensips[9336]: Method ACK from NATed UA - > RURI=sip:xxxxxx;user=phone;nat=yes F=sip:xxxxxx T=sip:xxxx@202.158.196.132 > C=<null> > > Mar 29 22:12:07 /usr/sbin/opensips[9336]: ACC: request acknowledged: > timestamp=1301436727;method=ACK;from_tag=7d81dea5-6b91-4499-b7a2-77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf9eca@xxxx4;code=200;reason=OK > > Mar 29 22:12:15 /usr/sbin/opensips[9323]: INFO:core:parse_first_line: empty > or bad first line > > Mar 29 22:12:15 /usr/sbin/opensips[9323]: INFO:core:parse_first_line: bad > message > > Mar 29 22:12:15 /usr/sbin/opensips[9323]: ERROR:core:parse_msg: message=<> > > Mar 29 22:12:15 /usr/sbin/opensips[9323]: ERROR:core:receive_msg: parse_msg > failed > > Mar 29 22:12:34 rtpproxy[11501]: INFO:handle_command: delete request failed: > session 9332ee00-d9215935-5a7d0-22cf9eca@xxxx, tags > 7d81dea5-6b91-4499-b7a2-77dff783a179-43141483/1219087299 not found > > > > However, a successful call (i.e. from NATed to public) has much more output, > like below. > > > > Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session > 825186551-1946...@bjc.bgi.b.bbc, tag 1615321429;1 requested, type strong > > Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session on a port > 64286 created, tag 1615321429;1 > > Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: pre-filling caller's > address with Public IP of ADSL:45020 > > Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session > 825186551-1946...@bjc.bgi.b.bbc, tag 1615321429;2 requested, type strong > > Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: new session on a port > 37262 created, tag 1615321429;2 > > Mar 29 22:22:23 rtpproxy[11548]: INFO:handle_command: pre-filling caller's > address with Public IP of ADSL:23420 > > > > BTW, I am running opensips v1.6.2 and rtpproxy version > > /usr/bin/rtpproxy -v > > Basic version: 20040107 > > Extension 20050322: Support for multiple RTP streams and MOH > > Extension 20060704: Support for extra parameter in the V command > > Extension 20071116: Support for RTP re-packetization > > Extension 20071218: Support for forking (copying) RTP stream > > Extension 20080403: Support for RTP statistics querying > > Extension 20081102: Support for setting codecs in the update/lookup command > > Extension 20081224: Support for session timeout notifications > > > > Thanks, > > Leon > > > > From: users-boun...@lists.opensips.org > [mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea > Sent: Friday, 25 March 2011 8:25 PM > To: users@lists.opensips.org > Subject: Re: [OpenSIPS-Users] inconsistence nathelper behavior > > > > Hi Leon, > > You should run rtpproxy with '-d DBUG'. You can find the logs in > /var/log/syslog. > > Regards, > Razvan > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
