No subject

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.Li at 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=A0 force_rtp_proxy() as I am still on v1.6.2.
>
> Regards,
>
> Leon
>
>
>
> From: users-bounces at lists.opensips.org
> [mailto:users-bounces at 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=3Dsip:xxxxxxxxxxxxxxxxxxxxxxxxx
>
> Mar 29 22:12:05 /usr/sbin/opensips[9336]: Alias Found, New
> RURI=3Dxxxxxxxxxxxxxxxxxxxx
>
> 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 at 192.168.1.112:19463;user=3Dphone
>
> 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 at 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=3D1301436727;method=3DINVITE;from_tag=3D7d81dea5-6b91-4499-b7a2=
-77dff783a179-43141483;to_tag=3D1219087299;call_id=3D9332ee00-d9215935-5a=
7d0-22cf9eca at xxxx;code=3D200;reason=3DOK
>
> Mar 29 22:12:07 /usr/sbin/opensips[9336]: Method ACK from NATed UA -
> RURI=3Dsip:xxxxxx;user=3Dphone;nat=3Dyes F=3Dsip:xxxxxx =
T=3Dsip:xxxx at 202.158.196.132
> C=3D<null>
>
> Mar 29 22:12:07 /usr/sbin/opensips[9336]: ACC: request acknowledged:
> =
timestamp=3D1301436727;method=3DACK;from_tag=3D7d81dea5-6b91-4499-b7a2-77=
dff783a179-43141483;to_tag=3D1219087299;call_id=3D9332ee00-d9215935-5a7d0=
-22cf9eca at xxxx4;code=3D200;reason=3DOK
>
> 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=3D<>
>
> 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 at 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-19463-7 at 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-19463-7 at 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-bounces at lists.opensips.org
> [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea
> Sent: Friday, 25 March 2011 8:25 PM
> To: users at 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 at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>