[OpenSIPS-Devel] [ opensips-Bugs-3190322 ] Content-Length and $du

SourceForge.net noreply at sourceforge.net
Thu Mar 3 11:36:03 CET 2011


Bugs item #3190322, was opened at 2011-02-23 18:59
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3190322&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: trunk
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: Content-Length and $du

Initial Comment:
Hi Guys,

My scenario is:
Origination -> Opensips Proxy -> Opensips B2B -> Termination

I have the $avp(s:fwd_ip) parameter that contains the destination uri.

What I am doing is:

$du = $avp(s:fwd_ip);
b2b_init_request("top hiding");

You can see what happens upon a call: http://pastebin.com/xP2SpPGb

Shortly, upon sending the call from the B2B to the termination, the line:
  a=nortpproxy:yes
is truncated to:
  a=nortppro

That leads to the SDP body length to NOT match to the Content-Length value and my termination rejects the call.
If I use the rewritehostport() function, the issue does not exists, but that way I cannot dynamically set the destination uri (because rewritehostport() does not support AVP values).

My workaround to that issue is:
perl_exec("fwd","forward the call to the termination");
b2b_init_request("top hiding");

Where the fwd perl function does:
sub fwd {
        my $m = shift;
        my $ruri = OpenSIPS::AVP::get('fwd_ip');
        $m->rewrite_ruri("$ruri");
        return 1;
}

It will be much easier if everything worked using the initial method:
$du = $avp(s:fwd_ip);

Please take a look into that bug.

Thanks.
Kamen

----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2011-03-03 12:36

Message:
Hi Kamen,

The reason why the To header is changes is that you use the
"rewritehostport" function. It rewrites the domain part in the ruri and the
B2BUA takes what finds in RURI and puts in To header. You don't need that
function, just drop it.

Regards,
Anca

----------------------------------------------------------------------

Comment By: Kamen ()
Date: 2011-03-02 22:38

Message:
Hi Anca,

Ok, I just tested your fix.
Now I have an issue with the "To" header.

Test 1:
I'm doing:
rewritehostport("67.227.19.162:5060");

On the termination side, I got the following call:
INVITE sip:359883327749 at 67.227.19.162:5060 SIP/2.0
Via: SIP/2.0/UDP 188.241.117.149:5061;branch=z9hG4bKd265.5561daf1.0
To: sip:359883327749 at 67.227.19.162:5060
From: "kamen"
<sip:88888888888 at 188.241.117.149:5060>;tag=7f0faf11dec05d3d0b92e82278c02f6e


Test 2 (with the updated $du):
$avp(s:fwd_ip) = 'sip:359883327749 at 67.227.19.162:5060';
$du = $avp(s:fwd_ip);

On the termination side, I got the following:
INVITE sip:359883327749:@67.227.19.162:5060 SIP/2.0
Via: SIP/2.0/UDP 188.241.117.149:5061;branch=z9hG4bKe086.f02b5083.0
To: sip:359883327749 at 188.241.117.149:5061
From: "kamen"
<sip:88888888888 at 188.241.117.149:5060>;tag=03023e1862b6574dee02e4e4375d639c



As you can see, the To header becomes invalid when I use $du. Could you
please fix that too :)

Thanks
-- Kamen

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2011-03-02 13:56

Message:
Hi Kamen,

I have fixed this in both trunk and 1.6 branch. Please update your code.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Ovidiu Sas (osas)
Date: 2011-02-25 15:15

Message:
Forgot to mention, there were 8 missing bytes in my case too.
The whole message is truncated by 8 bytes regardless of the length of
Content-Length.

----------------------------------------------------------------------

Comment By: Ovidiu Sas (osas)
Date: 2011-02-25 15:03

Message:
It seems that I ran into a similar issue, although in a different setup.
The problem seems to be related to the fact that the INVITE has a Route
header and the length of the Route header is not properly computed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3190322&group_id=232389



More information about the Devel mailing list