Sorry, forgot to add my config:
route[3] {
#---- NAT fixup ----#
#---- RTPproxy handling ----#
if (is_method("BYE|CANCEL")) {
unforce_rtp_proxy();
} else if (is_method("INVITE")) {
#---- Activates the RTP Proxy for the CALLEE ---#
#force_rtp_proxy();
if (has_body("application/sdp")) {
if (rtpproxy_offer())
rtpproxy_answer();
} else {
rtpproxy_offer();
}
} else if (is_method("ACK") && has_body("application/sdp"))
rtpproxy_answer();
# catch and fix replies
t_on_reply("2");
}
onreply_route[2] {
xlog("incoming reply\n");
#---- Handling of the SDP for the 200 or 183 reply ----#
#---- If behind nat (flags 5 or 6) start RTP Proxy ----#
#---- Activates the RTP Proxy for the CALLER ----#
if ( is_method("INVITE") && (isflagset(5) || isbflagset(6)) &&
has_body("application/sdp")) {
force_rtp_proxy();
}
#---- If the CALLEE is behind NAT, fix the CONTACT HF ----#
if (isbflagset(6)) {
fix_nated_contact();
search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
}
}
Regards,
Leon
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Leon Li
Sent: Friday, 8 April 2011 11:40 AM
To: Ovidiu Sas; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] inconsistence nathelper behavior
Thanks Ovidiu,
I gave a go but no luck.
The DSP is offered in a "200 OK" from NATed endpoint, however, I couldn't find
a way to check against "200 OK" and offer rtpproxy (ie. rewrite c= part).
anyway I can modify a 200 OK response?
Regards,
Leon
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ovidiu Sas
Sent: Friday, 1 April 2011 10:20 AM
To: OpenSIPS users mailling list
Cc: Leon Li
Subject: Re: [OpenSIPS-Users] inconsistence nathelper behavior
>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 <[email protected]> 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: [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-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:[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-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
> [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
>
>
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
