[OpenSIPS-Users] Using b2bua top hiding plus dispatcher module

[David Santiago]

Hi Anca,

I have finally been able to eliminate the loop and get the INVITEs being
sent to the internal jain slee server by doing a rewritehostport before the
b2b_init_request:

...
rewritehostport("10.253.22.143:5060");
b2b_init_request("top hiding");
...

This way, the INVITE generated by the b2bua module has the destination
correctly set to the internal jain slee server, instead of the public ip
address of the opensips server.


Regards,
David

On Tue, Oct 19, 2010 at 11:39 AM, Anca Vamanu <anca at opensips.org> wrote:

>  Hi David,
>
>
> On 10/18/2010 05:29 PM, David Santiago wrote:
>
> Hi again,
>
> I have made several changes to the script so that I can successfully add,
> for instance, a custom header to the INVITE request that the b2bua generates
> after receiving an external one. I'm doing it in a local_route block which
> is the supposed way to process an outgoing INVITE request that is going to
> be sent by the b2bua module, right?
>
> but.. I'm not being able to set the destination of such INVITE to the place
> I want. I have tried the following:
>
>    - ds_select_dst() function: it works in the main route block, but it
>    cannot be used in a local_route block.
>    - modifying $du variable. I can successfully modify this variable, but
>    it has no effect on where the INVITE is being sent to.
>    - rewriteuri() function: same result as modifying $du variable.
>
> I need that outgoing INVITE to be sent to a specific host and port, but I
> do not see how to modify the current behaviour which is that the INVITE is
> being sent to the public ip address of the opensips server, which in turn
> generates a loop as that INVITE is processed by the b2bua and a new INVITE
> is sent out to that same address again.
>
>
>  You can of course prevent this loop by calling b2b_init_request only if
> the Invite does not come from the same instance of OpenSIPS, as I suggested
> to you in the previous mail:
>
> *if (!has_totag() && is_method("INVITE") && !(src_ip=="MY_IP" &&
> src_port=="MY_PORT")) {
> *
> *     b2b_init_request("top hiding");
>     exit;
> }*
>
> I will implement the feature to take the value from $du if set hopefully in
> the following days. I will let you know.
>
>
> Regards,
>
> --
> Anca Vamanuwww.voice-system.ro
>
>
>
>
> Regards,
> David
>
> On Thu, Oct 14, 2010 at 9:08 AM, Anca Vamanu <anca at opensips.org> wrote:
>
>> Hi David,
>>
>> The dispatcher is working right - just that if you use b2bua it doesn't
>> have no effect as it does not use the newly set $du. Since it is sent
>> again to your opensips you can do a filter after the source address of
>> the message and do processing needed for the Invite going out if the
>> source is itself.
>>
>> if (!has_totag() && is_method("INVITE") && !(src_ip=="MY_IP" &&
>> src_port=="MY_PORT")) {
>>      b2b_init_request("top hiding");
>>     exit;
>> }
>>  ....
>> the rest of the changes needed.
>>
>> Anyhow, I should add using the $du as the outbound proxy for the newly
>> generated request on the features to implement list.
>>
>> Regards,
>> Anca
>>
>>
>> On 10/13/2010 12:19 PM, David Santiago wrote:
>> > I'll check it later, but the fact is that I have to solve first the
>> > problem that prevents the INVITEs generated by OpenSIPs to be sent to
>> > the internal jain slee server.
>> >
>> > I have confirmed that after the call to ds_select(), the value of $du
>> > points to such server (which has been obtained from the
>> > /opt/opensipsnotls/etc/opensips/dispatcher.list file), but the INVITEs
>> > are not sent there, but to the public IP address of the OpenSIPs
>> > server. Without the b2bua "setup", the dispatcher has been working
>> > fine in other tests I've made...
>> >
>> >
>> > Regards,
>> > David
>> >
>>
>
>
> _______________________________________________
> 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/20101019/29e53b23/attachment.htm