next_branch function, NAT and PATH (RFC 3327)

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

next_branch function, NAT and PATH (RFC 3327)

Mauro Davì

Hi All,

 

I’m using a SIP Server connected to a SIP Proxy (load balancer)

When a client behind NAT is connected to the SIP flatform all works fine, except one issue:

If I call an AOR via parallel fork all goes fine…

But if I use a serial forking, when I call the next_branch function to handle a serial forking the INVITE from the server isn’t sent to the SIP Proxy (the outbound proxy defined in the PATH HF of the REGISTER).

It seems that also the received parameter isn’t used… The INVITE go direct to the private IP of the client behind NAT…

It is a mistake in my opensips configuration or it is a real BUG…

 

Could anyone give me a suggestion?

 

Thanks in advance

            MD

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] next_branch function, NAT and PATH (RFC 3327)

Iñaki Baz Castillo
2009/5/14 Mauro Davi' <[hidden email]>:
> Hi All,

Hi Mauro, please send such a question just to "users" maillist (but no "devel").

Thanks.


--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] next_branch function, NAT and PATH (RFC 3327)

Bogdan-Andrei Iancu
In reply to this post by Mauro Davì
Hi Mauro,

The serialize_branches() and next_branch() should push the path and
received field in the next serial branches - could you post the relevant
part of the script where you do use these 2 functions (also what version
on opensips are you using) ?

Regards,
Bogdan

Mauro Davi' wrote:

>
> Hi All,
>
> I’m using a SIP Server connected to a SIP Proxy (load balancer)
>
> When a client behind NAT is connected to the SIP flatform all works
> fine, except one issue:
>
> If I call an AOR via parallel fork all goes fine…
>
> But if I use a serial forking, when I call the next_branch function to
> handle a serial forking the INVITE from the server isn’t sent to the
> SIP Proxy (the outbound proxy defined in the PATH HF of the REGISTER).
>
> It seems that also the received parameter isn’t used… The INVITE go
> direct to the private IP of the client behind NAT…
>
> It is a mistake in my opensips configuration or it is a real BUG…
>
> Could anyone give me a suggestion?
>
> Thanks in advance
>
> MD
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Devel mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: next_branch function, NAT and PATH (RFC 3327)

Alex Hermann-2
In reply to this post by Mauro Davì
On Thursday 14 May 2009 16:40:08 Mauro Davi' wrote:
> If I call an AOR via parallel fork all goes fine...
Parallel forking seems ok, but in reality it isn't. You just don't notice
because you use only 1 load-balancer. If the AOR has multiple contact
registered via multiple load-balancers, all contacts use the path of the first
contact.

>> But if I use a serial forking, when I call the next_branch function to
> handle a serial forking the INVITE from the server isn't sent to the SIP
> Proxy (the outbound proxy defined in the PATH HF of the REGISTER).
Indeed, on serial forking Path is ignored completely except for the first
branch.

> It seems that also the received parameter isn't used... The INVITE go
> direct to the private IP of the client behind NAT...
>
> It is a mistake in my opensips configuration or it is a real BUG...
It's a bug and has been present for quite some time.

Alex.


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

R: [OpenSIPS-Devel] next_branch function, NAT and PATH (RFC 3327)

Mauro Davì
In reply to this post by Bogdan-Andrei Iancu
Hi Bogdan,

below the piece of code that handle a serial forking call to more than
one contact.
The idea is to search on a DB a list of contact to add associated with a
sip uri.
For example when I call sip:[hidden email] I add 3 contacts:

[hidden email]
[hidden email]
[hidden email]

I call the append_branch() function followed by a lookup function (to
resolve the real IP address.

If all the contacts have the same IP address, all goes fine, otherwise
the call after the first one goes wrong because the outbound proxy isn't
set.
I'm using the opensips version 1.5.1.

Loadmodule "registrar.so"

modparam("registrar", "use_path", 1)
modparam("registrar", "path_mode", 0)
modparam("registrar", "path_use_received", 1)

                        avp_db_query("SELECT count(*) FROM hunt_group
WHERE username = '$oU' and domain='$od'","$avp(s:hg_row_count)");
                        if($avp(s:hg_row_count)!=0)
                        {
                                avp_db_query("SELECT id,domain FROM
hunt_group WHERE username = '$oU' and
domain='$od'","$avp(s:hg_id);$avp(s:hg_domain)");
                                xlog("L_INFO","Id <$avp(s:hg_id)>,
domain<$avp(s:hg_domain)>\n");
                                route(11);
                                avp_db_query("SELECT count(*) FROM
hunt_group_detail WHERE hg_id = $avp(s:hg_id)","$avp(s:hgd_row_count)");
                           if($avp(s:hgd_row_count)!=0)
                       {
                                        avp_db_query("SELECT
s.username,h.q_value FROM subscriber s,hunt_group_detail h WHERE
s.id=h.uuid AND hg_id = $avp(s:hg_id) ORDER BY h.q_value
ASC","$avp(s:hgd_username);$avp(s:qvalue)");
                                        $var(i)=0;
                                        $var(append_branch)=0;
                                        xlog("L_INFO","CHECK Number of
hunt group users <$avp(s:hgd_row_count)>\n");
                                        while ($var(i) <
$avp(s:hgd_row_count)) {
                                                $var(sip_address) =
"sip:" + $(avp(s:hgd_username)[$var(i)]) + "@" + $avp(s:hg_domain);
                                                $avp(s:q_value) = "0." +
$(avp(s:qvalue)[$var(i)]);
                                                xlog("L_INFO","Try to
add <$var(sip_address)> URI with qvalue <$avp(s:q_value)>\n");
                                                if
(registered("location","$var(sip_address)")) {
                                                        if
($var(append_branch)!=0) {
 
append_branch();
                                                }
       
$var(append_branch) = 1;
                                                        $ru =
$var(sip_address);
 
xlog("L_INFO","Adding <$var(sip_address)> URI with qvalue
<$avp(s:q_value)>\n");
 
lookup("location");
                                                }
                                                $var(i) = $var(i) + 1;
                                        }
                                        xlog("L_INFO","CHECK
serialize_branches\n");
                                        serialize_branches(1);
                                        setflag(10);
                                }
                                t_on_failure(3);
                                t_relay();
                                exit;
                        }


failure_route[3]
{
        if (t_was_cancelled()) {
                exit();
        }
        if (isflagset(10)) {
                if
(t_check_status("4[0-9][0-9]|5[0-9][0-9]|6[0-9][0-9]")) {
                        if (next_branches()) {
                                t_on_failure(3);
                                t_relay();
                        } else {
                                xlog("L_INFO", "Service Unavailable -
M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
                                route(11);
                                $avp(s:status_code)="503";
                                acc_db_request("Service Unavailable",
"acc");
                        }
                }
        }
}

Regards,
        MD

-----Messaggio originale-----
Da: Bogdan-Andrei Iancu [mailto:[hidden email]]
Inviato: sabato 16 maggio 2009 09:15
A: Mauro Davi'
Cc: [hidden email]
Oggetto: Re: [OpenSIPS-Devel] next_branch function, NAT and PATH (RFC
3327)

Hi Mauro,

The serialize_branches() and next_branch() should push the path and
received field in the next serial branches - could you post the relevant

part of the script where you do use these 2 functions (also what version

on opensips are you using) ?

Regards,
Bogdan

Mauro Davi' wrote:

>
> Hi All,
>
> I'm using a SIP Server connected to a SIP Proxy (load balancer)
>
> When a client behind NAT is connected to the SIP flatform all works
> fine, except one issue:
>
> If I call an AOR via parallel fork all goes fine...
>
> But if I use a serial forking, when I call the next_branch function to

> handle a serial forking the INVITE from the server isn't sent to the
> SIP Proxy (the outbound proxy defined in the PATH HF of the REGISTER).
>
> It seems that also the received parameter isn't used... The INVITE go
> direct to the private IP of the client behind NAT...
>
> It is a mistake in my opensips configuration or it is a real BUG...
>
> Could anyone give me a suggestion?
>
> Thanks in advance
>
> MD
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Devel mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

R: R: [OpenSIPS-Devel] next_branch function, NAT and PATH (RFC 3327)

Mauro Davì
Sorry, there is a mistake...

If all contacts have the same q-value....

-----Messaggio originale-----
Da: [hidden email] [mailto:[hidden email]] Per conto di Mauro Davi'
Inviato: lunedì 18 maggio 2009 10:25
A: Bogdan-Andrei Iancu
Cc: [hidden email]
Oggetto: [OpenSIPS-Users] R: [OpenSIPS-Devel] next_branch function,NAT and PATH (RFC 3327)

Hi Bogdan,

below the piece of code that handle a serial forking call to more than
one contact.
The idea is to search on a DB a list of contact to add associated with a
sip uri.
For example when I call sip:[hidden email] I add 3 contacts:

[hidden email]
[hidden email]
[hidden email]

I call the append_branch() function followed by a lookup function (to
resolve the real IP address.

If all the contacts have the same IP address, all goes fine, otherwise
the call after the first one goes wrong because the outbound proxy isn't
set.
I'm using the opensips version 1.5.1.

Loadmodule "registrar.so"

modparam("registrar", "use_path", 1)
modparam("registrar", "path_mode", 0)
modparam("registrar", "path_use_received", 1)

                        avp_db_query("SELECT count(*) FROM hunt_group
WHERE username = '$oU' and domain='$od'","$avp(s:hg_row_count)");
                        if($avp(s:hg_row_count)!=0)
                        {
                                avp_db_query("SELECT id,domain FROM
hunt_group WHERE username = '$oU' and
domain='$od'","$avp(s:hg_id);$avp(s:hg_domain)");
                                xlog("L_INFO","Id <$avp(s:hg_id)>,
domain<$avp(s:hg_domain)>\n");
                                route(11);
                                avp_db_query("SELECT count(*) FROM
hunt_group_detail WHERE hg_id = $avp(s:hg_id)","$avp(s:hgd_row_count)");
                           if($avp(s:hgd_row_count)!=0)
                       {
                                        avp_db_query("SELECT
s.username,h.q_value FROM subscriber s,hunt_group_detail h WHERE
s.id=h.uuid AND hg_id = $avp(s:hg_id) ORDER BY h.q_value
ASC","$avp(s:hgd_username);$avp(s:qvalue)");
                                        $var(i)=0;
                                        $var(append_branch)=0;
                                        xlog("L_INFO","CHECK Number of
hunt group users <$avp(s:hgd_row_count)>\n");
                                        while ($var(i) <
$avp(s:hgd_row_count)) {
                                                $var(sip_address) =
"sip:" + $(avp(s:hgd_username)[$var(i)]) + "@" + $avp(s:hg_domain);
                                                $avp(s:q_value) = "0." +
$(avp(s:qvalue)[$var(i)]);
                                                xlog("L_INFO","Try to
add <$var(sip_address)> URI with qvalue <$avp(s:q_value)>\n");
                                                if
(registered("location","$var(sip_address)")) {
                                                        if
($var(append_branch)!=0) {
 
append_branch();
                                                }
       
$var(append_branch) = 1;
                                                        $ru =
$var(sip_address);
 
xlog("L_INFO","Adding <$var(sip_address)> URI with qvalue
<$avp(s:q_value)>\n");
 
lookup("location");
                                                }
                                                $var(i) = $var(i) + 1;
                                        }
                                        xlog("L_INFO","CHECK
serialize_branches\n");
                                        serialize_branches(1);
                                        setflag(10);
                                }
                                t_on_failure(3);
                                t_relay();
                                exit;
                        }


failure_route[3]
{
        if (t_was_cancelled()) {
                exit();
        }
        if (isflagset(10)) {
                if
(t_check_status("4[0-9][0-9]|5[0-9][0-9]|6[0-9][0-9]")) {
                        if (next_branches()) {
                                t_on_failure(3);
                                t_relay();
                        } else {
                                xlog("L_INFO", "Service Unavailable -
M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
                                route(11);
                                $avp(s:status_code)="503";
                                acc_db_request("Service Unavailable",
"acc");
                        }
                }
        }
}

Regards,
        MD

-----Messaggio originale-----
Da: Bogdan-Andrei Iancu [mailto:[hidden email]]
Inviato: sabato 16 maggio 2009 09:15
A: Mauro Davi'
Cc: [hidden email]
Oggetto: Re: [OpenSIPS-Devel] next_branch function, NAT and PATH (RFC
3327)

Hi Mauro,

The serialize_branches() and next_branch() should push the path and
received field in the next serial branches - could you post the relevant

part of the script where you do use these 2 functions (also what version

on opensips are you using) ?

Regards,
Bogdan

Mauro Davi' wrote:

>
> Hi All,
>
> I'm using a SIP Server connected to a SIP Proxy (load balancer)
>
> When a client behind NAT is connected to the SIP flatform all works
> fine, except one issue:
>
> If I call an AOR via parallel fork all goes fine...
>
> But if I use a serial forking, when I call the next_branch function to

> handle a serial forking the INVITE from the server isn't sent to the
> SIP Proxy (the outbound proxy defined in the PATH HF of the REGISTER).
>
> It seems that also the received parameter isn't used... The INVITE go
> direct to the private IP of the client behind NAT...
>
> It is a mistake in my opensips configuration or it is a real BUG...
>
> Could anyone give me a suggestion?
>
> Thanks in advance
>
> MD
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Devel mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: next_branch function, NAT and PATH (RFC 3327)

Bogdan-Andrei Iancu
In reply to this post by Alex Hermann-2
Hi Alex,

Alex Hermann wrote:
> On Thursday 14 May 2009 16:40:08 Mauro Davi' wrote:
>  
>> If I call an AOR via parallel fork all goes fine...
>>    
> Parallel forking seems ok, but in reality it isn't. You just don't notice
> because you use only 1 load-balancer. If the AOR has multiple contact
> registered via multiple load-balancers, all contacts use the path of the first
> contact.
>  
For parallel forking after  lookup("location") should work - usrloc
keeps the PATH string for each contact and accordingly push it in
branches. Also TM module is using the PATH string separately for each
branch it sends out.

Maybe it is something I miss here, so please let me know why do you say
that all branches are sent out via the PATH of the first contact.
>  
>>> But if I use a serial forking, when I call the next_branch function to
>>>      
>> handle a serial forking the INVITE from the server isn't sent to the SIP
>> Proxy (the outbound proxy defined in the PATH HF of the REGISTER).
>>    
> Indeed, on serial forking Path is ignored completely except for the first
> branch.
>  

yes, because the serialize branches engine does not store the PATH
string :(...that is a bug indeed.
>  
>> It seems that also the received parameter isn't used... The INVITE go
>> direct to the private IP of the client behind NAT...
>>    
yes, because the received info is also not stored in the serialized
branches...another BUG.

Regards,
Bogdan

>> It is a mistake in my opensips configuration or it is a real BUG...
>>    
> It's a bug and has been present for quite some time.
>
> Alex.
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: R: R: [OpenSIPS-Devel] next_branch function, NAT and PATH (RFC 3327)

Bogdan-Andrei Iancu
In reply to this post by Mauro Davì
Hi Mauro,

Just to clarify for the list - the problem seams to be a bug (or an
miss) in the serialize branches engine - it does not store the received
and path information.

I already open a bug report about this -
https://sourceforge.net/tracker/?func=detail&aid=2795294&group_id=232389&atid=1086410

Thanks and regards,
Bogdan

Mauro Davi' wrote:

> Sorry, there is a mistake...
>
> If all contacts have the same q-value....
>
> -----Messaggio originale-----
> Da: [hidden email] [mailto:[hidden email]] Per conto di Mauro Davi'
> Inviato: lunedì 18 maggio 2009 10:25
> A: Bogdan-Andrei Iancu
> Cc: [hidden email]
> Oggetto: [OpenSIPS-Users] R: [OpenSIPS-Devel] next_branch function,NAT and PATH (RFC 3327)
>
> Hi Bogdan,
>
> below the piece of code that handle a serial forking call to more than
> one contact.
> The idea is to search on a DB a list of contact to add associated with a
> sip uri.
> For example when I call sip:[hidden email] I add 3 contacts:
>
> [hidden email]
> [hidden email]
> [hidden email]
>
> I call the append_branch() function followed by a lookup function (to
> resolve the real IP address.
>
> If all the contacts have the same IP address, all goes fine, otherwise
> the call after the first one goes wrong because the outbound proxy isn't
> set.
> I'm using the opensips version 1.5.1.
>
> Loadmodule "registrar.so"
>
> modparam("registrar", "use_path", 1)
> modparam("registrar", "path_mode", 0)
> modparam("registrar", "path_use_received", 1)
>
> avp_db_query("SELECT count(*) FROM hunt_group
> WHERE username = '$oU' and domain='$od'","$avp(s:hg_row_count)");
>                         if($avp(s:hg_row_count)!=0)
>                         {
> avp_db_query("SELECT id,domain FROM
> hunt_group WHERE username = '$oU' and
> domain='$od'","$avp(s:hg_id);$avp(s:hg_domain)");
> xlog("L_INFO","Id <$avp(s:hg_id)>,
> domain<$avp(s:hg_domain)>\n");
> route(11);
> avp_db_query("SELECT count(*) FROM
> hunt_group_detail WHERE hg_id = $avp(s:hg_id)","$avp(s:hgd_row_count)");
>                            if($avp(s:hgd_row_count)!=0)
>                        {
> avp_db_query("SELECT
> s.username,h.q_value FROM subscriber s,hunt_group_detail h WHERE
> s.id=h.uuid AND hg_id = $avp(s:hg_id) ORDER BY h.q_value
> ASC","$avp(s:hgd_username);$avp(s:qvalue)");
> $var(i)=0;
>                                         $var(append_branch)=0;
>                                         xlog("L_INFO","CHECK Number of
> hunt group users <$avp(s:hgd_row_count)>\n");
> while ($var(i) <
> $avp(s:hgd_row_count)) {
>                                                 $var(sip_address) =
> "sip:" + $(avp(s:hgd_username)[$var(i)]) + "@" + $avp(s:hg_domain);
>                                                 $avp(s:q_value) = "0." +
> $(avp(s:qvalue)[$var(i)]);
> xlog("L_INFO","Try to
> add <$var(sip_address)> URI with qvalue <$avp(s:q_value)>\n");
> if
> (registered("location","$var(sip_address)")) {
> if
> ($var(append_branch)!=0) {
>  
> append_branch();
>                                                 }
>
> $var(append_branch) = 1;
> $ru =
> $var(sip_address);
>  
> xlog("L_INFO","Adding <$var(sip_address)> URI with qvalue
> <$avp(s:q_value)>\n");
>  
> lookup("location");
> }
> $var(i) = $var(i) + 1;
> }
>                                         xlog("L_INFO","CHECK
> serialize_branches\n");
>                                         serialize_branches(1);
> setflag(10);
> }
> t_on_failure(3);
>                                 t_relay();
> exit;
>                         }
>
>
> failure_route[3]
> {
> if (t_was_cancelled()) {
>                 exit();
>         }
> if (isflagset(10)) {
>                 if
> (t_check_status("4[0-9][0-9]|5[0-9][0-9]|6[0-9][0-9]")) {
>                         if (next_branches()) {
> t_on_failure(3);
>                                 t_relay();
> } else {
> xlog("L_INFO", "Service Unavailable -
> M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
> route(11);
> $avp(s:status_code)="503";
> acc_db_request("Service Unavailable",
> "acc");
> }
> }
> }
> }
>
> Regards,
> MD
>
> -----Messaggio originale-----
> Da: Bogdan-Andrei Iancu [mailto:[hidden email]]
> Inviato: sabato 16 maggio 2009 09:15
> A: Mauro Davi'
> Cc: [hidden email]
> Oggetto: Re: [OpenSIPS-Devel] next_branch function, NAT and PATH (RFC
> 3327)
>
> Hi Mauro,
>
> The serialize_branches() and next_branch() should push the path and
> received field in the next serial branches - could you post the relevant
>
> part of the script where you do use these 2 functions (also what version
>
> on opensips are you using) ?
>
> Regards,
> Bogdan
>
> Mauro Davi' wrote:
>  
>> Hi All,
>>
>> I'm using a SIP Server connected to a SIP Proxy (load balancer)
>>
>> When a client behind NAT is connected to the SIP flatform all works
>> fine, except one issue:
>>
>> If I call an AOR via parallel fork all goes fine...
>>
>> But if I use a serial forking, when I call the next_branch function to
>>    
>
>  
>> handle a serial forking the INVITE from the server isn't sent to the
>> SIP Proxy (the outbound proxy defined in the PATH HF of the REGISTER).
>>
>> It seems that also the received parameter isn't used... The INVITE go
>> direct to the private IP of the client behind NAT...
>>
>> It is a mistake in my opensips configuration or it is a real BUG...
>>
>> Could anyone give me a suggestion?
>>
>> Thanks in advance
>>
>> MD
>>
>>
>>    
> ------------------------------------------------------------------------
>  
>> _______________________________________________
>> Devel mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>  
>>    
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: next_branch function, NAT and PATH (RFC 3327)

Alex Hermann-2
In reply to this post by Bogdan-Andrei Iancu
On Friday 22 May 2009, Bogdan-Andrei Iancu wrote:

> Alex Hermann wrote:
> > On Thursday 14 May 2009 16:40:08 Mauro Davi' wrote:
> >> If I call an AOR via parallel fork all goes fine...
> >
> > Parallel forking seems ok, but in reality it isn't. You just don't
> > notice because you use only 1 load-balancer. If the AOR has multiple
> > contact registered via multiple load-balancers, all contacts use the
> > path of the first contact.
>
> For parallel forking after  lookup("location") should work - usrloc
> keeps the PATH string for each contact and accordingly push it in
> branches. Also TM module is using the PATH string separately for each
> branch it sends out.
>
> Maybe it is something I miss here, so please let me know why do you say
> that all branches are sent out via the PATH of the first contact.

That's what I observed a few months ago. It's been a while since I tried and
noticed the failures, so maybe it is ok now, or, maybe I messed up and it
was ok the first time. I'll check with a more current version.


Alex.

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: next_branch function, NAT and PATH (RFC 3327)

Bogdan-Andrei Iancu
Hi Alex,

Alex wrote:

> On Friday 22 May 2009, Bogdan-Andrei Iancu wrote:
>  
>> Alex Hermann wrote:
>>    
>>> On Thursday 14 May 2009 16:40:08 Mauro Davi' wrote:
>>>      
>>>> If I call an AOR via parallel fork all goes fine...
>>>>        
>>> Parallel forking seems ok, but in reality it isn't. You just don't
>>> notice because you use only 1 load-balancer. If the AOR has multiple
>>> contact registered via multiple load-balancers, all contacts use the
>>> path of the first contact.
>>>      
>> For parallel forking after  lookup("location") should work - usrloc
>> keeps the PATH string for each contact and accordingly push it in
>> branches. Also TM module is using the PATH string separately for each
>> branch it sends out.
>>
>> Maybe it is something I miss here, so please let me know why do you say
>> that all branches are sent out via the PATH of the first contact.
>>    
>
> That's what I observed a few months ago. It's been a while since I tried and
> noticed the failures, so maybe it is ok now, or, maybe I messed up and it
> was ok the first time. I'll check with a more current version.
>  
I already opened a bug for the serial forking part - I'll wait for some
confirmation from you on the parallel forking part.

Thanks and regards,
Bogdan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: next_branch function, NAT and PATH (RFC 3327)

Alex Hermann
On Monday 25 May 2009, Bogdan-Andrei Iancu wrote:
> >> Alex Hermann wrote:
> >>> Parallel forking seems ok, but in reality it isn't. You just don't
> >>> notice because you use only 1 load-balancer. If the AOR has multiple
> >>> contact registered via multiple load-balancers, all contacts use the
> >>> path of the first contact.
> I already opened a bug for the serial forking part - I'll wait for some
> confirmation from you on the parallel forking part.

It seems my memory failed me. I just checked and the behaviour for parallel
forking is correct. Sorry for the noise.

--
Greetings,

Alex Hermann


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: next_branch function, NAT and PATH (RFC 3327)

Bogdan-Andrei Iancu
Alex Hermann wrote:

> On Monday 25 May 2009, Bogdan-Andrei Iancu wrote:
>  
>>>> Alex Hermann wrote:
>>>>        
>>>>> Parallel forking seems ok, but in reality it isn't. You just don't
>>>>> notice because you use only 1 load-balancer. If the AOR has multiple
>>>>> contact registered via multiple load-balancers, all contacts use the
>>>>> path of the first contact.
>>>>>          
>> I already opened a bug for the serial forking part - I'll wait for some
>> confirmation from you on the parallel forking part.
>>    
>
> It seems my memory failed me. I just checked and the behaviour for parallel
> forking is correct. Sorry for the noise.
>  
OK - perfect :)

Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users