[OpenSIPS-Users] inconsistence nathelper behavior

[Leon Li]

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-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=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 at 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 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=1301436727;method=INVITE;from_tag=7d81dea5-6b91-4499-b7a2-77df
f783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf
9eca at 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
7d0-22cf9eca at 202.158.207.34;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 at 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-77dff78
3a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-22cf9ec
a at 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
-22cf9eca at 202.158.207.34;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 at xxxx
<mailto:9332ee00-d9215935-5a7d0-22cf9eca at 202.158.207.34> , 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110401/0af46bbe/attachment-0001.htm>