[OpenSIPS-Users] Rtp proxy issue

[michel freiha]

Dear Alex,

I did what you asked me to do and I still getting the same error....Please
find below the config:


if(!cr_route("default", "0", "$rU", "$rU", "call_id")){
       sl_send_reply("403", "Not allowed");
     } else {
         # In cas of failure, re-route the request
          t_on_failure("1");
 t_on_reply("1");
force_rtp_proxy();


t_relay();
  }



onreply_route[1] {
#  if (t_check_status("2[0-9][0-9]") )
 if((t_check_status("200|183|180") && search("Content_Type:
application/sdp")) || search("Content-Type: application/sdp"))


{
        force_rtp_proxy();
  }
exit;
}



Is there anything that I should add?

Regards

On Sun, Mar 8, 2009 at 11:59 PM, Alex Balashov <abalashov at evaristesys.com>wrote:

> It means you are applying the NAT UAC test function for SDP to a request
> that does not have an SDP payload.
>
> It should only be applied to messages that contain SDP payloads.  Easy way
> to check:
>
>
>   if(search("Content-Type: application/sdp"))
>
> Also, only the following kinds of messages can contain SDP descriptors:
>
> 1) Initial INVITEs;
>
> 2) Sequential INVITEs;
>
> 3) 200 OKs to INVITE transactions;
>
> 4) Non-100 1xx provisional messages -- these are usually 183 Session in
> Progress and 180 Ringing messages.  However, technically, any non-100 1xx
> message can contain an SDP body per the RFC.  In practise, this is rare, so
> t_check_status("200|183|180") will work for most scenarios. But if you want
> to be strictly correct, do:
>
>  if((t_check_status("200|183|180") && search("Content_Type:
> application/sdp")) || search("Content-Type: application/sdp"))
>
> michel freiha wrote:
>
>  Hi all,
>> I'm getting the below error when trying to make a call through OpenSIPS
>>
>> DBG:core:parse_headers: flags=ffffffffffffffff
>> Mar  6 20:43:29 [7117] ERROR:nathelper:extract_body: message body has
>> length zero
>> Mar  6 20:43:29 [7117] ERROR:nathelper:force_rtp_proxy2_f: can't extract
>> body from the message
>>
>> Can you explain please how this is affecting the call specially that the
>> call is working fine
>>
>> Regards
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> --
> Alex Balashov
> Evariste Systems
> Web    : http://www.evaristesys.com/
> Tel    : (+1) (678) 954-0670
> Direct : (+1) (678) 954-0671
> Mobile : (+1) (678) 237-1775
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090309/8d4f1245/attachment.htm