[OpenSIPS-Users] inconsistence nathelper behavior

Thu Mar 31 15:18:21 CEST 2011

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-77dff783a179-43141483;to_tag=1219087299;call_id=9332ee00-d9215935-5a7d0-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-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 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
>
> On 03/25/2011 06:58 AM, Leon Li wrote:
>
> Thanks Razvan for your reply,
>
> Could you kindly instruct me how to turn on debug level for rtpproxy?
>
> Regards,
>
> Leon
>
> *From:*users-bounces at lists.opensips.org 
> <mailto:users-bounces at lists.opensips.org> 
> [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Razvan Crainea
> *Sent:* Friday, 25 March 2011 1:07 AM
> *To:* OpenSIPS users mailling list
> *Subject:* Re: [OpenSIPS-Users] inconsistence nathelper behavior
>
> Hello Leon,
>
> As you can see, OpenSIPS receives an invalid port from RTPProxy, so 
> the problem seems to be there. Can you please set a lower debug level 
> for RTPProxy and paste me the log for this call?
>
> Regards,
> Razvan
>
> On 03/24/2011 02:35 AM, Leon Li wrote:
>
> Hello all,
>
> I've got a problem of one way voice when making a call from a public 
> side to private side, where the callee on private side can't hear 
> caller from public side. However, if the call is initialled from 
> private side, everything is fine.
>
> Here is my topology.
>
> EP1 (public IP) à Cisco CUCM (public IP) à OpenSIPs (public IP with 
> rtpproxy) ß Home router (NATed) ß EP2 (private IP).
>
> After enabled the debug as below, I found when EP1 calls EP2, 
> nathelper request a rtpproxy port but received an "0".
>
> Mar 23 23:44:22 [23719] DBG:nathelper:force_rtp_proxy: Forcing body:
>
> [v=0
>
> o=xxxxxxxxxxxxx 8000 8000 IN IP4 192.168.1.112
>
> s=SIP Call
>
> c=IN IP4 192.168.1.112
>
> t=0 0
>
> m=audio 49866 RTP/AVP 0 8 18 9 101
>
> a=sendrecv
>
> a=rtpmap:0 PCMU/8000
>
> a=ptime:20
>
> a=rtpmap:8 PCMA/8000
>
> a=rtpmap:18 G729/8000
>
> a=fmtp:18 annexb=no
>
> a=rtpmap:9 G722/8000
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-15
>
> m=video 21778 RTP/AVP 99 100 34
>
> b=AS:384
>
> a=sendrecv
>
> a=rtpmap:99 H264/90000
>
> a=fmtp:99 profile-level-id=428014; packetization-mode=0; 
> sprop-parameter-sets=Z0KADJWgUH5A,aM4Ecg==
>
> a=rtpmap:100 H263-1998/90000
>
> a=fmtp:100 CIF=1; QCIF=1
>
> a=rtpmap:34 H263/90000
>
> a=fmtp:34 CIF=1; QCIF=1]
>
> Mar 23 23:44:22 [23719] DBG:core:parse_headers: flags=40
>
> Mar 23 23:44:22 [23719] DBG:core:parse_to_param: 
> tag=7d81dea5-6b91-4499-b7a2-77dff783a179-43138246
>
> Mar 23 23:44:22 [23719] DBG:core:parse_to: end of header reached, state=29
>
> Mar 23 23:44:22 [23719] DBG:core:parse_to: display={"Leon Li"}, 
> ruri={sip:3537 at 202.158.207.34}
>
> *Mar 23 23:44:22 [23719] DBG:nathelper:force_rtp_proxy_body: proxy 
> reply: 0*
>
> *Mar 23 23:44:22 [23719] ERROR:nathelper:force_rtp_proxy_body: 
> incorrect port 0 in reply from rtp proxy*
>
> In the debug on calls from EP2 to EP1, I got
>
> Mar 24 00:06:02 [24298] DBG:nathelper:force_rtp_proxy_body: proxy 
> reply: 48334
>
> Mar 24 00:06:02 [24298] DBG:nathelper:force_rtp_proxy_body: proxy 
> reply: 48126
>
> Can anyone shed some lights on what could be wrong?
>
> Thanks,
>
> Leon
>
>   
>   
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   
>   
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110331/493595f7/attachment-0001.htm>