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: [email protected] [mailto:[email protected]] 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:[email protected]: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-77df f783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf 9eca@xxxx;code=200;reason=OK <mailto:timestamp=1301436727;method=INVITE;from_tag=7d81dea5-6b91-4499-b 7a2-77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a [email protected];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:[email protected] C=<null> Mar 29 22:12:07 /usr/sbin/opensips[9336]: ACC: request acknowledged: timestamp=1301436727;method=ACK;from_tag=7d81dea5-6b91-4499-b7a2-77dff78 3a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf9ec a@xxxx4;code=200;reason=OK <mailto:timestamp=1301436727;method=ACK;from_tag=7d81dea5-6b91-4499-b7a2 -77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0 [email protected];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 <mailto:[email protected]> , 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 [email protected], 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 [email protected], 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: [email protected] [mailto:[email protected]] On Behalf Of Razvan Crainea Sent: Friday, 25 March 2011 8:25 PM To: [email protected] 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 [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
