21 Apr
2009
21 Apr
'09
6:35 p.m.
Hello guys,
Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example:
P1 & P2 share same usrloc database.
UA1 registers to P1 UA2 registers to P2
UA1 calls UA2
UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is).
Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2.
So currently I have:
UA1 INVITE -> P1 INVITE -> UA2
I wish to have:
UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2
Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks!
21 Apr
21 Apr
8:05 p.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
El Martes, 21 de Abril de 2009, Brandon Armstead escribió:
Hello guys,
Is there a method upon using lookup("location") to also pull out the"socket" information for the original location the UAC registered to, for scenarios of this example:
P1 & P2 share same usrloc database.
UA1 registers to P1 UA2 registers to P2
UA1 calls UA2
UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is).
Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2.
For this, you need the "path" module and also reading its RFC 3327: http://tools.ietf.org/html/rfc3327
Note that registrar and/or location modules (not sure which one now) also takes part in this behaviour, so read these module parameters related to "path" feature.
--
Iñaki Baz Castillo ibc@aliax.net
22 Apr
22 Apr
12:31 p.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Maybe this can help you:
http://www.kamailio.org/docs/modules/devel/registrar.html#id2530856 http://www.kamailio.org/docs/modules/devel/registrar.html#id2531067
Brandon Armstead wrote:
Hello guys,
Is there a method upon using lookup("location") to also pull out the"socket" information for the original location the UAC registered to, for scenarios of this example:
P1 & P2 share same usrloc database.
UA1 registers to P1 UA2 registers to P2
UA1 calls UA2
UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is).
Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2.
So currently I have:
UA1 INVITE -> P1 INVITE -> UA2
I wish to have:
UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2
Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks!
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
4:44 p.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Klaus,
That second link looks like exactly what I'm looking for, thanks!
On Wed, Apr 22, 2009 at 5:31 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
Maybe this can help you:
http://www.kamailio.org/docs/modules/devel/registrar.html#id2530856 http://www.kamailio.org/docs/modules/devel/registrar.html#id2531067
Brandon Armstead wrote:
Hello guys,
Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example:
P1 & P2 share same usrloc database.
UA1 registers to P1 UA2 registers to P2
UA1 calls UA2
UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is).
Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2.
So currently I have:
UA1 INVITE -> P1 INVITE -> UA2
I wish to have:
UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2
Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks!
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
23 Apr
23 Apr
6:54 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Brandon Armstead schrieb:
Klaus,
That second link looks like exactly what I'm looking for, thanks!
It is just that you have to call the fetch.. function (1st link) first, othervise the PVs will not be available.
klaus
On Wed, Apr 22, 2009 at 5:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Maybe this can help you: http://www.kamailio.org/docs/modules/devel/registrar.html#id2530856 http://www.kamailio.org/docs/modules/devel/registrar.html#id2531067 Brandon Armstead wrote: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
7:18 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Klaus,
This is perfect as far as what I'm looking for, although this is going to be for a production environment, so I'm a little hesitant right now as to throwing it into production via this method. Would you happen to have any better suggestions other than a avp_db_query to pull the socket from openser.location for the current $rU, or is that as good as its going to get?
Thanks!
(sent reply to all)
On Wed, Apr 22, 2009 at 11:54 PM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
Brandon Armstead schrieb:
Klaus,
That second link looks like exactly what I'm looking for, thanks!
It is just that you have to call the fetch.. function (1st link) first, othervise the PVs will not be available.
klaus
On Wed, Apr 22, 2009 at 5:31 AM, Klaus Darilion < klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Maybe this can help you:
http://www.kamailio.org/docs/modules/devel/registrar.html#id2530856 http://www.kamailio.org/docs/modules/devel/registrar.html#id2531067
Brandon Armstead wrote:
Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks!
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
7:31 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Hi Brandon!
Back to the original email ....
Brandon Armstead schrieb:
Hello guys,
Is there a method upon using lookup("location") to also pull out the"socket" information for the original location the UAC registered to, for scenarios of this example:
P1 & P2 share same usrloc database.
UA1 registers to P1 UA2 registers to P2
UA1 calls UA2
UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is).
Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2.
So currently I have:
UA1 INVITE -> P1 INVITE -> UA2
I wish to have:
UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2
Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks!
I think the nat_traversal module can not help you in this case, nor nathelper.
One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing).
Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2.
Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1
klaus
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
7:54 p.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Klaus,
So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call:
if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; }
On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as:
[INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?)
Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be?
I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks!
On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
Hi Brandon!
Back to the original email ....
Brandon Armstead schrieb:
Hello guys,
Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example:
P1 & P2 share same usrloc database.
UA1 registers to P1 UA2 registers to P2
UA1 calls UA2
UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is).
Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2.
So currently I have:
UA1 INVITE -> P1 INVITE -> UA2
I wish to have:
UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2
Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks!
I think the nat_traversal module can not help you in this case, nor nathelper.
One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing).
Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2.
Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1
klaus
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
7:59 p.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Hello,
On 04/23/2009 09:54 PM, Brandon Armstead wrote:
Klaus,
So I took you and Inaki's input and essentially constructed asetup like so after the lookup("location") call:
if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; }
On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as:
[INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?)
you can use a special header that accumulates the id's of the servers the request has been through. You check when choosing next destination.
Cheers, Daniel
Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be?
I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks!
On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Hi Brandon! Back to the original email .... Brandon Armstead schrieb: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! I think the nat_traversal module can not help you in this case, nor nathelper. One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing). Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2. Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1 klaus ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
--
Daniel-Constantin Mierla
http://www.asipto.com/
24 Apr
24 Apr
8:18 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Brandon Armstead schrieb:
Klaus,
So I took you and Inaki's input and essentially constructed a setuplike so after the lookup("location") call:
if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; }
1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly.
2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER.
3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy.
Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client).
e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1
Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3.
So, P1 is the originating proxy. P2 is the serving proxy of Bob2. ....
We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only.
route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); }
# downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); }
t_on_reply("1"); t_relay(); exit(); } ...
# I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; }
... # a new request - thus I am the originating proxy
if ($dU looks like phone number) { ... route to Gateway.... exit; }
if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1");
# activate reply route to activate RTP proxy t_on_reply("1");
# NAT traversal fix_nated_contact();
record_route(); t_relay(); exit; }
branch_route[1]{ if(isbflagset(1)){ # oh, that's me
# add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both");
# add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes");
force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller");
# we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } }
reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } }
Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port.
regards klaus
On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as:
[INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?)
Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be?
I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks!
On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Hi Brandon! Back to the original email .... Brandon Armstead schrieb: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! I think the nat_traversal module can not help you in this case, nor nathelper. One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing). Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2. Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1 klaus ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
28 Apr
28 Apr
12:42 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Klaus, Inaki, Daniel,
Thanks! Sorry I did not see this email come through, I'm going to go ahead and give this method a go, and I'll update with the results, I have optimistic views.
As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help!
Sincerely, Brandon.
On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
Brandon Armstead schrieb:
Klaus,
So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call:
if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; }
- The above code has to be in the branch_route block - otherwise multiple
registrations of a single user are not handled correctly.
- you are rewriting the RURI. You should not do that as some clients wants
to the in the RURI the Contact provided during REGISTER.
- probably you use fix_nated_register() to store the public IP:port of the
client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy.
Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client).
e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1
Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3.
So, P1 is the originating proxy. P2 is the serving proxy of Bob2. ....
We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only.
route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); }
# downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); }
t_on_reply("1"); t_relay(); exit(); } ...
# I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; }
... # a new request - thus I am the originating proxy
if ($dU looks like phone number) { ... route to Gateway.... exit; }
if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1");
# activate reply route to activate RTP proxy t_on_reply("1");
# NAT traversal fix_nated_contact();
record_route(); t_relay(); exit; }
branch_route[1]{ if(isbflagset(1)){ # oh, that's me
# add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both");
# add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes");
force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller");
# we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } }
reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } }
Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port.
regards klaus
On each Proxy, I changed the code appropriately excluding the Proxy from
itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as:
[INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?)
Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be?
I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks!
On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion < klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Hi Brandon!
Back to the original email ....
Brandon Armstead schrieb:
Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks!I think the nat_traversal module can not help you in this case, nor nathelper.
One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing).
Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2.
Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1
klaus
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
29 Apr
29 Apr
8:53 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Hey guys,
Still facing a few challenges and seeing if any further input, I'm specifically trying inaki's suggestions / method, but here are the current problems:
sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.comsip%3ACALLER@sip.example.comtu= sip:CALLEE@sip.example.com sip%3ACALLEE@sip.example.com si=99.XX.XX.XX flag=96 du=<null>
This call is not sent to Proxy B (this is a result of bflag not being set) ??? My question is "Why", I look at the AOR / usrloc and they both have the "same exact flags set", this call is rather sent directly to UAC endpoint.
---
Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.comsip%3ACALLER@sip.example.comtu= sip:CALLEE@sip.example.com sip%3ACALLEE@sip.example.com si=99.XX.XX.XX flag=64 du=sip:PROXY_B;transport=udp;
This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp?
Again, thank you for all and any help, thanks!
On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead brandon@cryy.com wrote:
Klaus, Inaki, Daniel,
Thanks! Sorry I did not see this email come through, I'm going to goahead and give this method a go, and I'll update with the results, I have optimistic views.
As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help!
Sincerely, Brandon.
On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
Brandon Armstead schrieb:
Klaus,
So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call:
if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; }
- The above code has to be in the branch_route block - otherwise multiple
registrations of a single user are not handled correctly.
- you are rewriting the RURI. You should not do that as some clients
wants to the in the RURI the Contact provided during REGISTER.
- probably you use fix_nated_register() to store the public IP:port of
the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy.
Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client).
e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1
Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3.
So, P1 is the originating proxy. P2 is the serving proxy of Bob2. ....
We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only.
route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); }
# downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); }
t_on_reply("1"); t_relay(); exit(); } ...
# I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; }
... # a new request - thus I am the originating proxy
if ($dU looks like phone number) { ... route to Gateway.... exit; }
if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1");
# activate reply route to activate RTP proxy t_on_reply("1");
# NAT traversal fix_nated_contact();
record_route(); t_relay(); exit; }
branch_route[1]{ if(isbflagset(1)){ # oh, that's me
# add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both");
# add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes");
force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller");
# we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } }
reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } }
Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port.
regards klaus
On each Proxy, I changed the code appropriately excluding the Proxy from
itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as:
[INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?)
Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be?
I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks!
On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion < klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Hi Brandon!
Back to the original email ....
Brandon Armstead schrieb:
Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks!I think the nat_traversal module can not help you in this case, nor nathelper.
One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing).
Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2.
Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1
klaus
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
9:02 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Hello,
On 04/29/2009 10:53 AM, Brandon Armstead wrote:
Hey guys,
Still facing a few challenges and seeing if any further input, I'mspecifically trying inaki's suggestions / method, but here are the current problems:
sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 mailto:77e4c600-147767fb@172.16.1.35][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.com mailto:sip%3ACALLER@sip.example.com tu=sip:CALLEE@sip.example.com mailto:sip%3ACALLEE@sip.example.com si=99.XX.XX.XX flag=96 du=<null>
This call is not sent to Proxy B (this is a result of bflag not being set) ???
is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the address of that proxy. It is null in the log above.
Cheers, Daniel
My question is "Why", I look at the AOR / usrloc and they both have the "same exact flags set", this call is rather sent directly to UAC endpoint.
Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 mailto:77e4c600-147767fb@172.16.1.35][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.com mailto:sip%3ACALLER@sip.example.com tu=sip:CALLEE@sip.example.com mailto:sip%3ACALLEE@sip.example.com si=99.XX.XX.XX flag=64 du=sip:PROXY_B;transport=udp;
This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp?
Again, thank you for all and any help, thanks!
On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead <brandon@cryy.com mailto:brandon@cryy.com> wrote:
Klaus, Inaki, Daniel, Thanks! Sorry I did not see this email come through, I'm going to go ahead and give this method a go, and I'll update with the results, I have optimistic views. As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help! Sincerely, Brandon. On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> wrote: Brandon Armstead schrieb: Klaus, So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call: if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; } 1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly. 2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER. 3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy. Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client). e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1 Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3. So, P1 is the originating proxy. P2 is the serving proxy of Bob2. .... We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only. route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); } # downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); } t_on_reply("1"); t_relay(); exit(); } ... # I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; } ... # a new request - thus I am the originating proxy if ($dU looks like phone number) { ... route to Gateway.... exit; } if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1"); # activate reply route to activate RTP proxy t_on_reply("1"); # NAT traversal fix_nated_contact(); record_route(); t_relay(); exit; } branch_route[1]{ if(isbflagset(1)){ # oh, that's me # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both"); # add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes"); force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller"); # we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } } reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } } Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port. regards klaus On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as: [INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?) Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be? I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks! On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> wrote: Hi Brandon! Back to the original email .... Brandon Armstead schrieb: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! I think the nat_traversal module can not help you in this case, nor nathelper. One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing). Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2. Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1 klaus ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
--
Daniel-Constantin Mierla
http://www.asipto.com/
9:11 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Daniel,
No that would be the UAC (I have two clients behind the same NAT). The problem is it looks like the branch flag is not being set for both for some reason (when comparing) even though in the database it is the same? Take a look at the flag= value from each of those logs (this is one call) to a UAC with two registrations line1/line2.
On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hello,
On 04/29/2009 10:53 AM, Brandon Armstead wrote:
Hey guys,
Still facing a few challenges and seeing if any further input, I'm specifically trying inaki's suggestions / method, but here are the current problems:
sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [ 77e4c600-147767fb@172.16.1.35 mailto:77e4c600-147767fb@172.16.1.35][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.comsip%3ACALLER@sip.example.com<mailto: sip%3ACALLER@sip.example.com sip%253ACALLER@sip.example.com> tu= sip:CALLEE@sip.example.com sip%3ACALLEE@sip.example.com <mailto: sip%3ACALLEE@sip.example.com sip%253ACALLEE@sip.example.com> si=99.XX.XX.XX flag=96 du=<null>
This call is not sent to Proxy B (this is a result of bflag not being set) ???
is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the address of that proxy. It is null in the log above.
Cheers, Daniel
My question is "Why", I look at the AOR / usrloc and they both have the
"same exact flags set", this call is rather sent directly to UAC endpoint.
Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [ 77e4c600-147767fb@172.16.1.35 mailto:77e4c600-147767fb@172.16.1.35][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.comsip%3ACALLER@sip.example.com<mailto: sip%3ACALLER@sip.example.com sip%253ACALLER@sip.example.com> tu= sip:CALLEE@sip.example.com sip%3ACALLEE@sip.example.com <mailto: sip%3ACALLEE@sip.example.com sip%253ACALLEE@sip.example.com> si=99.XX.XX.XX flag=64 du=sip:PROXY_B;transport=udp;
This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp?
Again, thank you for all and any help, thanks!
On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead <brandon@cryy.commailto: brandon@cryy.com> wrote:
Klaus, Inaki, Daniel,
Thanks! Sorry I did not see this email come through, I'mgoing to go ahead and give this method a go, and I'll update with the results, I have optimistic views.
As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help!
Sincerely, Brandon.
On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:
Brandon Armstead schrieb: Klaus, So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call: if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; } 1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly. 2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER. 3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy. Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client). e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1 Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3. So, P1 is the originating proxy. P2 is the serving proxy of Bob2. .... We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only. route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); } # downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); } t_on_reply("1"); t_relay(); exit(); } ... # I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; } ... # a new request - thus I am the originating proxy if ($dU looks like phone number) { ... route to Gateway.... exit; } if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1"); # activate reply route to activate RTP proxy t_on_reply("1"); # NAT traversal fix_nated_contact(); record_route(); t_relay(); exit; } branch_route[1]{ if(isbflagset(1)){ # oh, that's me # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both"); # add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes"); force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller"); # we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } } reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } } Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port. regards klaus On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as: [INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?) Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be? I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks! On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> wrote: Hi Brandon! Back to the original email .... Brandon Armstead schrieb: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! I think the nat_traversal module can not help you in this case, nor nathelper. One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing). Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2. Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1 klaus
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla http://www.asipto.com/
9:17 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
On 04/29/2009 11:11 AM, Brandon Armstead wrote:
Daniel,
No that would be the UAC (I have two clients behind the sameNAT). The problem is it looks like the branch flag is not being set for both for some reason (when comparing) even though in the database it is the same?
So you have the brach flag for nat and branch flags for next proxy, right? What is the value of branch flag? The value are different indeed, but some flags you are looking for might be set. It is easier spot if you print the hexa format of the flags rather than decimal one.
Cheers, Daniel
Take a look at the flag= value from each of those logs (this is one call) to a UAC with two registrations line1/line2.
On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, On 04/29/2009 10:53 AM, Brandon Armstead wrote: Hey guys, Still facing a few challenges and seeing if any further input, I'm specifically trying inaki's suggestions / method, but here are the current problems: sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.com <mailto:sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com>> tu=sip:CALLEE@sip.example.com <mailto:sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com>> si=99.XX.XX.XX flag=96 du=<null> This call is not sent to Proxy B (this is a result of bflag not being set) ??? is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the address of that proxy. It is null in the log above. Cheers, Daniel My question is "Why", I look at the AOR / usrloc and they both have the "same exact flags set", this call is rather sent directly to UAC endpoint. --- Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.com <mailto:sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com>> tu=sip:CALLEE@sip.example.com <mailto:sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com>> si=99.XX.XX.XX flag=64 du=sip:PROXY_B;transport=udp; This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp? Again, thank you for all and any help, thanks! On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead <brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> wrote: Klaus, Inaki, Daniel, Thanks! Sorry I did not see this email come through, I'm going to go ahead and give this method a go, and I'll update with the results, I have optimistic views. As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help! Sincerely, Brandon. On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> wrote: Brandon Armstead schrieb: Klaus, So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call: if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; } 1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly. 2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER. 3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy. Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client). e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1 Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3. So, P1 is the originating proxy. P2 is the serving proxy of Bob2. .... We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only. route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); } # downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); } t_on_reply("1"); t_relay(); exit(); } ... # I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; } ... # a new request - thus I am the originating proxy if ($dU looks like phone number) { ... route to Gateway.... exit; } if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1"); # activate reply route to activate RTP proxy t_on_reply("1"); # NAT traversal fix_nated_contact(); record_route(); t_relay(); exit; } branch_route[1]{ if(isbflagset(1)){ # oh, that's me # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both"); # add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes"); force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller"); # we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } } reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } } Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port. regards klaus On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as: [INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?) Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be? I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks! On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> wrote: Hi Brandon! Back to the original email .... Brandon Armstead schrieb: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! I think the nat_traversal module can not help you in this case, nor nathelper. One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing). Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2. Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1 klaus ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla http://www.asipto.com/
--
Daniel-Constantin Mierla
http://www.asipto.com/
9:32 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Daniel,
It looks like you helped me find part of the problem, apparently Proxy A was sharing same branch flag as the one I used to distinguish which proxy it was. I corrected this and now branch flag for branch 1 is 00000060, and branch 2 is 00000040, however now both branches are routed appropriately to the correct server, however the X-Duri (to restore to in the INVITE) is null. Do I need to save this value into an AVP after lookup("location")? Or should it be readily available in branch_route[], and for some reason my variable is null?
P.S. (recap) Proxy A NAT Branch Flag: 5 Proxy B NAT Branch Flag: 5
(Problem existed as used Flag 5 to distinguish "itself" as proxy) -- changed this to 4 so now:
Proxy A NAT Branch Flag: 4 Proxy B NAT Branch Flag: 6
Calls are routed to Proxy B
X-Duri: <null> (as it is null in Proxy A). I'm append_hf(X-Duri: $du) inside of branch_route[].
Thanks!
On Wed, Apr 29, 2009 at 2:17 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
On 04/29/2009 11:11 AM, Brandon Armstead wrote:
Daniel,
No that would be the UAC (I have two clients behind the same NAT). The problem is it looks like the branch flag is not being set for both for some reason (when comparing) even though in the database it is the same?
So you have the brach flag for nat and branch flags for next proxy, right? What is the value of branch flag? The value are different indeed, but some flags you are looking for might be set. It is easier spot if you print the hexa format of the flags rather than decimal one.
Cheers, Daniel
Take a look at the flag= value from each of those logs (this is one call)
to a UAC with two registrations line1/line2.
On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla < miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
On 04/29/2009 10:53 AM, Brandon Armstead wrote:
Hey guys, Still facing a few challenges and seeing if any further input, I'm specifically trying inaki's suggestions / method, but here are the current problems: sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.com<sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com>tu=sip:CALLEE@sip.example.com <sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com>>>si=99.XX.XX.XX flag=96 du=<null>
This call is not sent to Proxy B (this is a result of bflag not being set) ???is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the address of that proxy. It is null in the log above.
Cheers, Daniel
My question is "Why", I look at the AOR / usrloc and they both have the "same exact flags set", this call is rather sent directly to UAC endpoint. --- Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.com<sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com>tu=sip:CALLEE@sip.example.com <sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com>>>si=99.XX.XX.XX flag=64 du=sip:PROXY_B;transport=udp;
This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp? Again, thank you for all and any help, thanks! On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead <brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> wrote: Klaus, Inaki, Daniel, Thanks! Sorry I did not see this email come through, I'm going to go ahead and give this method a go, and I'll update with the results, I have optimistic views. As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help! Sincerely, Brandon. On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> wrote: Brandon Armstead schrieb: Klaus, So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call: if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; } 1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly. 2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER. 3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy. Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client). e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1 Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3. So, P1 is the originating proxy. P2 is the serving proxy of Bob2. .... We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only. route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); } # downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); } t_on_reply("1"); t_relay(); exit(); } ... # I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; } ... # a new request - thus I am the originating proxy if ($dU looks like phone number) { ... route to Gateway.... exit; } if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1"); # activate reply route to activate RTP proxy t_on_reply("1"); # NAT traversal fix_nated_contact(); record_route(); t_relay(); exit; } branch_route[1]{ if(isbflagset(1)){ # oh, that's me # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both"); # add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes"); force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller"); # we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } } reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } } Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port. regards klaus On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as: [INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?) Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be? I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks! On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> wrote: Hi Brandon! Back to the original email .... Brandon Armstead schrieb: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! I think the nat_traversal module can not help you in this case, nor nathelper. One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing). Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2. Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1 klaus
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users-- Daniel-Constantin Mierla http://www.asipto.com/
-- Daniel-Constantin Mierla http://www.asipto.com/
9:42 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
On 04/29/2009 11:32 AM, Brandon Armstead wrote:
Daniel,
It looks like you helped me find part of the problem, apparentlyProxy A was sharing same branch flag as the one I used to distinguish which proxy it was. I corrected this and now branch flag for branch 1 is 00000060, and branch 2 is 00000040, however now both branches are routed appropriately to the correct server, however the X-Duri (to restore to in the INVITE) is null.
I may not followed all discussion branch - the X-Duri is a header you append to the message? If yes, it is not visible immediately in the script, but you can see it when the messages is ent to the network.
Do I need to save this value into an AVP after lookup("location")?
What you need to do with it? Where is its values taken from?
Cheers, Daniel
Or should it be readily available in branch_route[], and for some reason my variable is null?
P.S. (recap) Proxy A NAT Branch Flag: 5 Proxy B NAT Branch Flag: 5
(Problem existed as used Flag 5 to distinguish "itself" as proxy) -- changed this to 4 so now:
Proxy A NAT Branch Flag: 4 Proxy B NAT Branch Flag: 6
Calls are routed to Proxy B
X-Duri: <null> (as it is null in Proxy A). I'm append_hf(X-Duri: $du) inside of branch_route[].
Thanks!
On Wed, Apr 29, 2009 at 2:17 AM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
On 04/29/2009 11:11 AM, Brandon Armstead wrote: Daniel, No that would be the UAC (I have two clients behind the same NAT). The problem is it looks like the branch flag is not being set for both for some reason (when comparing) even though in the database it is the same? So you have the brach flag for nat and branch flags for next proxy, right? What is the value of branch flag? The value are different indeed, but some flags you are looking for might be set. It is easier spot if you print the hexa format of the flags rather than decimal one. Cheers, Daniel Take a look at the flag= value from each of those logs (this is one call) to a UAC with two registrations line1/line2. On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> wrote: Hello, On 04/29/2009 10:53 AM, Brandon Armstead wrote: Hey guys, Still facing a few challenges and seeing if any further input, I'm specifically trying inaki's suggestions / method, but here are the current problems: sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.com <mailto:sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>>> tu=sip:CALLEE@sip.example.com <mailto:sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>>> si=99.XX.XX.XX flag=96 du=<null> This call is not sent to Proxy B (this is a result of bflag not being set) ??? is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the address of that proxy. It is null in the log above. Cheers, Daniel My question is "Why", I look at the AOR / usrloc and they both have the "same exact flags set", this call is rather sent directly to UAC endpoint. --- Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.com <mailto:sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>>> tu=sip:CALLEE@sip.example.com <mailto:sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>>> si=99.XX.XX.XX flag=64 du=sip:PROXY_B;transport=udp; This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp? Again, thank you for all and any help, thanks! On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead <brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>> wrote: Klaus, Inaki, Daniel, Thanks! Sorry I did not see this email come through, I'm going to go ahead and give this method a go, and I'll update with the results, I have optimistic views. As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help! Sincerely, Brandon. On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> wrote: Brandon Armstead schrieb: Klaus, So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call: if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; } 1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly. 2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER. 3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy. Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client). e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1 Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3. So, P1 is the originating proxy. P2 is the serving proxy of Bob2. .... We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only. route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); } # downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); } t_on_reply("1"); t_relay(); exit(); } ... # I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; } ... # a new request - thus I am the originating proxy if ($dU looks like phone number) { ... route to Gateway.... exit; } if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1"); # activate reply route to activate RTP proxy t_on_reply("1"); # NAT traversal fix_nated_contact(); record_route(); t_relay(); exit; } branch_route[1]{ if(isbflagset(1)){ # oh, that's me # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both"); # add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes"); force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller"); # we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } } reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } } Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port. regards klaus On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as: [INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?) Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be? I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks! On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>> wrote: Hi Brandon! Back to the original email .... Brandon Armstead schrieb: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! I think the nat_traversal module can not help you in this case, nor nathelper. One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing). Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2. Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1 klaus ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla http://www.asipto.com/ -- Daniel-Constantin Mierla http://www.asipto.com/
--
Daniel-Constantin Mierla
http://www.asipto.com/
9:45 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Daniel,
Yes I'm doing an append_hf("X-Duri: $du\r\n"); inside of branch_route[] i.e.:
branch_route[2] { if(isbflagset(4)){ # thats me! } else { # at this point X-Duri is null, so we are not saving it from the lookup? # we need to save this to pass onto Proxy B, however the value is NULL at this point, and at the point of Proxy B (when received). append_hf("X-Duri: $avp(s:duri)\r\n"); if(isbflagset(6)){ $du = "sip:PROXY_B;transport=udp;"; } }
xlog("L_INFO", "[$ci][branch_route][$T_branch_idx] ru=$ru fu=$fu tu=$tu si=$si flag=$bF du=$du"); }
Then when X-Duri reaches Proxy B, if I see the INVITE comes from Proxy A, I take X-Duri and restore "$du" with the correct value.
However this is causing issues now as the value is <null>, I've tried saving $du into avp after looking up usrloc, I've tried simply calling $du in branch_route[], and I've tried saving $du in loose_route() into an avp, all to no avail.
What am I missing here as far as passing the value of $du from branch route to header, to pass along to Proxy B.
Thanks again!
On Wed, Apr 29, 2009 at 2:42 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
On 04/29/2009 11:32 AM, Brandon Armstead wrote:
Daniel,
It looks like you helped me find part of the problem, apparently Proxy A was sharing same branch flag as the one I used to distinguish which proxy it was. I corrected this and now branch flag for branch 1 is 00000060, and branch 2 is 00000040, however now both branches are routed appropriately to the correct server, however the X-Duri (to restore to in the INVITE) is null.
I may not followed all discussion branch - the X-Duri is a header you append to the message? If yes, it is not visible immediately in the script, but you can see it when the messages is ent to the network.
Do I need to save this value into an AVP after lookup("location")?
What you need to do with it? Where is its values taken from?
Cheers, Daniel
Or should it be readily available in branch_route[], and for some reason
my variable is null?
P.S. (recap) Proxy A NAT Branch Flag: 5 Proxy B NAT Branch Flag: 5
(Problem existed as used Flag 5 to distinguish "itself" as proxy) -- changed this to 4 so now:
Proxy A NAT Branch Flag: 4 Proxy B NAT Branch Flag: 6
Calls are routed to Proxy B
X-Duri: <null> (as it is null in Proxy A). I'm append_hf(X-Duri: $du) inside of branch_route[].
Thanks!
On Wed, Apr 29, 2009 at 2:17 AM, Daniel-Constantin Mierla < miconda@gmail.com mailto:miconda@gmail.com> wrote:
On 04/29/2009 11:11 AM, Brandon Armstead wrote:
Daniel, No that would be the UAC (I have two clients behind the same NAT). The problem is it looks like the branch flag is not being set for both for some reason (when comparing) even though in the database it is the same?So you have the brach flag for nat and branch flags for next proxy, right? What is the value of branch flag? The value are different indeed, but some flags you are looking for might be set. It is easier spot if you print the hexa format of the flags rather than decimal one.
Cheers, Daniel
Take a look at the flag= value from each of those logs (this is one call) to a UAC with two registrations line1/line2. On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> wrote: Hello, On 04/29/2009 10:53 AM, Brandon Armstead wrote: Hey guys, Still facing a few challenges and seeing if any further input, I'm specifically trying inaki's suggestions / method, but here are the current problems: sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.com <sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com>tu=sip:CALLEE@sip.example.com<sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com>>>>si=99.XX.XX.XX
flag=96 du=<null> This call is not sent to Proxy B (this is a result of bflag not being set) ??? is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the address of that proxy. It is null in the log above. Cheers, Daniel My question is "Why", I look at the AOR / usrloc and they both have the "same exact flags set", this call is rather sent directly to UAC endpoint. --- Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.com <sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com>tu=sip:CALLEE@sip.example.com<sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com>>>>si=99.XX.XX.XX
flag=64 du=sip:PROXY_B;transport=udp; This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp? Again, thank you for all and any help, thanks! On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead <brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>> wrote: Klaus, Inaki, Daniel, Thanks! Sorry I did not see this email come through, I'm going to go ahead and give this method a go, and I'll update with the results, I have optimistic views. As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help! Sincerely, Brandon. On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> wrote: Brandon Armstead schrieb: Klaus, So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call: if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; } 1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly. 2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER. 3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy. Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client). e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1 Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3. So, P1 is the originating proxy. P2 is the serving proxy of Bob2. .... We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only. route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); } # downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); } t_on_reply("1"); t_relay(); exit(); } ... # I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; } ... # a new request - thus I am the originating proxy if ($dU looks like phone number) { ... route to Gateway.... exit; } if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1"); # activate reply route to activate RTP proxy t_on_reply("1"); # NAT traversal fix_nated_contact(); record_route(); t_relay(); exit; } branch_route[1]{ if(isbflagset(1)){ # oh, that's me # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both"); # add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes"); force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller"); # we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } } reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } } Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port. regards klaus On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as: [INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?) Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be? I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks! On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>> wrote: Hi Brandon! Back to the original email .... Brandon Armstead schrieb: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! I think the nat_traversal module can not help you in this case, nor nathelper. One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing). Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2. Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1 klaus
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>>http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla http://www.asipto.com/-- Daniel-Constantin Mierla http://www.asipto.com/
-- Daniel-Constantin Mierla http://www.asipto.com/
2:39 p.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Hello,
$du is set by usrloc only if there is a received value in the location record. Can you check if you have it in db?
Cheers, Daniel
On 04/29/2009 11:45 AM, Brandon Armstead wrote:
Daniel,
Yes I'm doing an append_hf("X-Duri: $du\r\n"); inside ofbranch_route[] i.e.:
branch_route[2] { if(isbflagset(4)){ # thats me! } else { # at this point X-Duri is null, so we are not saving it from the lookup? # we need to save this to pass onto Proxy B, however the value is NULL at this point, and at the point of Proxy B (when received). append_hf("X-Duri: $avp(s:duri)\r\n"); if(isbflagset(6)){ $du = "sip:PROXY_B;transport=udp;"; } }
xlog("L_INFO", "[$ci][branch_route][$T_branch_idx] ru=$ru fu=$futu=$tu si=$si flag=$bF du=$du"); }
Then when X-Duri reaches Proxy B, if I see the INVITE comes from Proxy A, I take X-Duri and restore "$du" with the correct value.
However this is causing issues now as the value is <null>, I've tried saving $du into avp after looking up usrloc, I've tried simply calling $du in branch_route[], and I've tried saving $du in loose_route() into an avp, all to no avail.
What am I missing here as far as passing the value of $du from branch route to header, to pass along to Proxy B.
Thanks again!
On Wed, Apr 29, 2009 at 2:42 AM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
On 04/29/2009 11:32 AM, Brandon Armstead wrote: Daniel, It looks like you helped me find part of the problem, apparently Proxy A was sharing same branch flag as the one I used to distinguish which proxy it was. I corrected this and now branch flag for branch 1 is 00000060, and branch 2 is 00000040, however now both branches are routed appropriately to the correct server, however the X-Duri (to restore to in the INVITE) is null. I may not followed all discussion branch - the X-Duri is a header you append to the message? If yes, it is not visible immediately in the script, but you can see it when the messages is ent to the network. Do I need to save this value into an AVP after lookup("location")? What you need to do with it? Where is its values taken from? Cheers, Daniel Or should it be readily available in branch_route[], and for some reason my variable is null? P.S. (recap) Proxy A NAT Branch Flag: 5 Proxy B NAT Branch Flag: 5 (Problem existed as used Flag 5 to distinguish "itself" as proxy) -- changed this to 4 so now: Proxy A NAT Branch Flag: 4 Proxy B NAT Branch Flag: 6 Calls are routed to Proxy B X-Duri: <null> (as it is null in Proxy A). I'm append_hf(X-Duri: $du) inside of branch_route[]. Thanks! On Wed, Apr 29, 2009 at 2:17 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> wrote: On 04/29/2009 11:11 AM, Brandon Armstead wrote: Daniel, No that would be the UAC (I have two clients behind the same NAT). The problem is it looks like the branch flag is not being set for both for some reason (when comparing) even though in the database it is the same? So you have the brach flag for nat and branch flags for next proxy, right? What is the value of branch flag? The value are different indeed, but some flags you are looking for might be set. It is easier spot if you print the hexa format of the flags rather than decimal one. Cheers, Daniel Take a look at the flag= value from each of those logs (this is one call) to a UAC with two registrations line1/line2. On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>> wrote: Hello, On 04/29/2009 10:53 AM, Brandon Armstead wrote: Hey guys, Still facing a few challenges and seeing if any further input, I'm specifically trying inaki's suggestions / method, but here are the current problems: sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.com <mailto:sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>>> tu=sip:CALLEE@sip.example.com <mailto:sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>>> si=99.XX.XX.XX flag=96 du=<null> This call is not sent to Proxy B (this is a result of bflag not being set) ??? is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the address of that proxy. It is null in the log above. Cheers, Daniel My question is "Why", I look at the AOR / usrloc and they both have the "same exact flags set", this call is rather sent directly to UAC endpoint. --- Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.com <mailto:sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>>> tu=sip:CALLEE@sip.example.com <mailto:sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>>> si=99.XX.XX.XX flag=64 du=sip:PROXY_B;transport=udp; This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp? Again, thank you for all and any help, thanks! On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead <brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>>> wrote: Klaus, Inaki, Daniel, Thanks! Sorry I did not see this email come through, I'm going to go ahead and give this method a go, and I'll update with the results, I have optimistic views. As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help! Sincerely, Brandon. On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>> wrote: Brandon Armstead schrieb: Klaus, So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call: if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; } 1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly. 2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER. 3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy. Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client). e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1 Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3. So, P1 is the originating proxy. P2 is the serving proxy of Bob2. .... We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only. route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); } # downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); } t_on_reply("1"); t_relay(); exit(); } ... # I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; } ... # a new request - thus I am the originating proxy if ($dU looks like phone number) { ... route to Gateway.... exit; } if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1"); # activate reply route to activate RTP proxy t_on_reply("1"); # NAT traversal fix_nated_contact(); record_route(); t_relay(); exit; } branch_route[1]{ if(isbflagset(1)){ # oh, that's me # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both"); # add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes"); force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller"); # we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } } reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } } Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port. regards klaus On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as: [INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?) Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be? I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks! On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>>> wrote: Hi Brandon! Back to the original email .... Brandon Armstead schrieb: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! I think the nat_traversal module can not help you in this case, nor nathelper. One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing). Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2. Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1 klaus ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla http://www.asipto.com/ -- Daniel-Constantin Mierla http://www.asipto.com/ -- Daniel-Constantin Mierla http://www.asipto.com/
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
--
Daniel-Constantin Mierla
http://www.asipto.com/
6:35 p.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Daniel,
You are correct it is not set for this usrloc. Should I be able to just not modify $du in this case? Thanks!
On Wed, Apr 29, 2009 at 7:39 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hello,
$du is set by usrloc only if there is a received value in the location record. Can you check if you have it in db?
Cheers, Daniel
On 04/29/2009 11:45 AM, Brandon Armstead wrote:
Daniel,
Yes I'm doing an append_hf("X-Duri: $du\r\n"); inside of branch_route[] i.e.:
branch_route[2] { if(isbflagset(4)){ # thats me! } else { # at this point X-Duri is null, so we are not saving it from the lookup? # we need to save this to pass onto Proxy B, however the value is NULL at this point, and at the point of Proxy B (when received). append_hf("X-Duri: $avp(s:duri)\r\n"); if(isbflagset(6)){ $du = "sip:PROXY_B;transport=udp;"; } }
xlog("L_INFO", "[$ci][branch_route][$T_branch_idx] ru=$ru fu=$fu tu=$tu si=$si flag=$bF du=$du"); }
Then when X-Duri reaches Proxy B, if I see the INVITE comes from Proxy A, I take X-Duri and restore "$du" with the correct value.
However this is causing issues now as the value is <null>, I've tried saving $du into avp after looking up usrloc, I've tried simply calling $du in branch_route[], and I've tried saving $du in loose_route() into an avp, all to no avail.
What am I missing here as far as passing the value of $du from branch route to header, to pass along to Proxy B.
Thanks again!
On Wed, Apr 29, 2009 at 2:42 AM, Daniel-Constantin Mierla < miconda@gmail.com mailto:miconda@gmail.com> wrote:
On 04/29/2009 11:32 AM, Brandon Armstead wrote:
Daniel, It looks like you helped me find part of the problem, apparently Proxy A was sharing same branch flag as the one I used to distinguish which proxy it was. I corrected this and now branch flag for branch 1 is 00000060, and branch 2 is 00000040, however now both branches are routed appropriately to the correct server, however the X-Duri (to restore to in the INVITE) is null.I may not followed all discussion branch - the X-Duri is a header you append to the message? If yes, it is not visible immediately in the script, but you can see it when the messages is ent to the network.
Do I need to save this value into an AVP after lookup("location")?What you need to do with it? Where is its values taken from?
Cheers, Daniel
Or should it be readily available in branch_route[], and for some reason my variable is null? P.S. (recap) Proxy A NAT Branch Flag: 5 Proxy B NAT Branch Flag: 5 (Problem existed as used Flag 5 to distinguish "itself" as proxy) -- changed this to 4 so now: Proxy A NAT Branch Flag: 4 Proxy B NAT Branch Flag: 6 Calls are routed to Proxy B X-Duri: <null> (as it is null in Proxy A). I'm append_hf(X-Duri: $du) inside of branch_route[]. Thanks! On Wed, Apr 29, 2009 at 2:17 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> wrote: On 04/29/2009 11:11 AM, Brandon Armstead wrote: Daniel, No that would be the UAC (I have two clients behind the same NAT). The problem is it looks like the branch flag is not being set for both for some reason (when comparing) even though in the database it is the same? So you have the brach flag for nat and branch flags for next proxy, right? What is the value of branch flag? The value are different indeed, but some flags you are looking for might be set. It is easier spot if you print the hexa format of the flags rather than decimal one. Cheers, Daniel Take a look at the flag= value from each of those logs (this is one call) to a UAC with two registrations line1/line2. On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>> wrote: Hello, On 04/29/2009 10:53 AM, Brandon Armstead wrote: Hey guys, Still facing a few challenges and seeing if any further input, I'm specifically trying inaki's suggestions / method, but here are the current problems: sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.com<sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com>tu=sip:CALLEE@sip.example.com<sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com>>>>>si=99.XX.XX.XX
flag=96 du=<null> This call is not sent to Proxy B (this is a result of bflag not being set) ??? is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the address of that proxy. It is null in the log above. Cheers, Daniel My question is "Why", I look at the AOR / usrloc and they both have the "same exact flags set", this call is rather sent directly to UAC endpoint. --- Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.com<sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com>tu=sip:CALLEE@sip.example.com<sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com>>>>>si=99.XX.XX.XX
flag=64 du=sip:PROXY_B;transport=udp; This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp? Again, thank you for all and any help, thanks! On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead <brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>>> wrote: Klaus, Inaki, Daniel, Thanks! Sorry I did not see this email come through, I'm going to go ahead and give this method a go, and I'll update with the results, I have optimistic views. As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help! Sincerely, Brandon. On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>> wrote: Brandon Armstead schrieb: Klaus, So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call: if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; } 1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly. 2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER. 3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy. Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client). e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1 Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3. So, P1 is the originating proxy. P2 is the serving proxy of Bob2. .... We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only. route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); } # downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); } t_on_reply("1"); t_relay(); exit(); } ... # I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; } ... # a new request - thus I am the originating proxy if ($dU looks like phone number) { ... route to Gateway.... exit; } if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1"); # activate reply route to activate RTP proxy t_on_reply("1"); # NAT traversal fix_nated_contact(); record_route(); t_relay(); exit; } branch_route[1]{ if(isbflagset(1)){ # oh, that's me # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both"); # add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes"); force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller"); # we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } } reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } } Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port. regards klaus On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as: [INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?) Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be? I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks! On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>>> wrote: Hi Brandon! Back to the original email .... Brandon Armstead schrieb: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! I think the nat_traversal module can not help you in this case, nor nathelper. One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing). Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2. Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1 klaus
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>>>http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla http://www.asipto.com/ -- Daniel-Constantin Mierla http://www.asipto.com/-- Daniel-Constantin Mierla http://www.asipto.com/
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla http://www.asipto.com/
30 Apr
30 Apr
8:16 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Hello,
On 04/29/2009 08:35 PM, Brandon Armstead wrote:
Daniel,
You are correct it is not set for this usrloc. Should I be ableto just not modify $du in this case?
I do not understand what you mean now?!?!
Cheers, Daniel
Thanks!
On Wed, Apr 29, 2009 at 7:39 AM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, $du is set by usrloc only if there is a received value in the location record. Can you check if you have it in db? Cheers, Daniel On 04/29/2009 11:45 AM, Brandon Armstead wrote: Daniel, Yes I'm doing an append_hf("X-Duri: $du\r\n"); inside of branch_route[] i.e.: branch_route[2] { if(isbflagset(4)){ # thats me! } else { # at this point X-Duri is null, so we are not saving it from the lookup? # we need to save this to pass onto Proxy B, however the value is NULL at this point, and at the point of Proxy B (when received). append_hf("X-Duri: $avp(s:duri)\r\n"); if(isbflagset(6)){ $du = "sip:PROXY_B;transport=udp;"; } } xlog("L_INFO", "[$ci][branch_route][$T_branch_idx] ru=$ru fu=$fu tu=$tu si=$si flag=$bF du=$du"); } Then when X-Duri reaches Proxy B, if I see the INVITE comes from Proxy A, I take X-Duri and restore "$du" with the correct value. However this is causing issues now as the value is <null>, I've tried saving $du into avp after looking up usrloc, I've tried simply calling $du in branch_route[], and I've tried saving $du in loose_route() into an avp, all to no avail. What am I missing here as far as passing the value of $du from branch route to header, to pass along to Proxy B. Thanks again! On Wed, Apr 29, 2009 at 2:42 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> wrote: On 04/29/2009 11:32 AM, Brandon Armstead wrote: Daniel, It looks like you helped me find part of the problem, apparently Proxy A was sharing same branch flag as the one I used to distinguish which proxy it was. I corrected this and now branch flag for branch 1 is 00000060, and branch 2 is 00000040, however now both branches are routed appropriately to the correct server, however the X-Duri (to restore to in the INVITE) is null. I may not followed all discussion branch - the X-Duri is a header you append to the message? If yes, it is not visible immediately in the script, but you can see it when the messages is ent to the network. Do I need to save this value into an AVP after lookup("location")? What you need to do with it? Where is its values taken from? Cheers, Daniel Or should it be readily available in branch_route[], and for some reason my variable is null? P.S. (recap) Proxy A NAT Branch Flag: 5 Proxy B NAT Branch Flag: 5 (Problem existed as used Flag 5 to distinguish "itself" as proxy) -- changed this to 4 so now: Proxy A NAT Branch Flag: 4 Proxy B NAT Branch Flag: 6 Calls are routed to Proxy B X-Duri: <null> (as it is null in Proxy A). I'm append_hf(X-Duri: $du) inside of branch_route[]. Thanks! On Wed, Apr 29, 2009 at 2:17 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>> wrote: On 04/29/2009 11:11 AM, Brandon Armstead wrote: Daniel, No that would be the UAC (I have two clients behind the same NAT). The problem is it looks like the branch flag is not being set for both for some reason (when comparing) even though in the database it is the same? So you have the brach flag for nat and branch flags for next proxy, right? What is the value of branch flag? The value are different indeed, but some flags you are looking for might be set. It is easier spot if you print the hexa format of the flags rather than decimal one. Cheers, Daniel Take a look at the flag= value from each of those logs (this is one call) to a UAC with two registrations line1/line2. On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>>> wrote: Hello, On 04/29/2009 10:53 AM, Brandon Armstead wrote: Hey guys, Still facing a few challenges and seeing if any further input, I'm specifically trying inaki's suggestions / method, but here are the current problems: sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>>][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.com <mailto:sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com>>>>> tu=sip:CALLEE@sip.example.com <mailto:sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com>>>>> si=99.XX.XX.XX flag=96 du=<null> This call is not sent to Proxy B (this is a result of bflag not being set) ??? is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the address of that proxy. It is null in the log above. Cheers, Daniel My question is "Why", I look at the AOR / usrloc and they both have the "same exact flags set", this call is rather sent directly to UAC endpoint. --- Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>>][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.com <mailto:sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com>>>>> tu=sip:CALLEE@sip.example.com <mailto:sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com>>>>> si=99.XX.XX.XX flag=64 du=sip:PROXY_B;transport=udp; This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp? Again, thank you for all and any help, thanks! On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead <brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>>>> wrote: Klaus, Inaki, Daniel, Thanks! Sorry I did not see this email come through, I'm going to go ahead and give this method a go, and I'll update with the results, I have optimistic views. As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help! Sincerely, Brandon. On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>>> wrote: Brandon Armstead schrieb: Klaus, So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call: if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; } 1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly. 2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER. 3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy. Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client). e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1 Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3. So, P1 is the originating proxy. P2 is the serving proxy of Bob2. .... We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only. route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); } # downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); } t_on_reply("1"); t_relay(); exit(); } ... # I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; } ... # a new request - thus I am the originating proxy if ($dU looks like phone number) { ... route to Gateway.... exit; } if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1"); # activate reply route to activate RTP proxy t_on_reply("1"); # NAT traversal fix_nated_contact(); record_route(); t_relay(); exit; } branch_route[1]{ if(isbflagset(1)){ # oh, that's me # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both"); # add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes"); force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller"); # we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } } reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } } Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port. regards klaus On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as: [INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?) Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be? I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks! On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>>>> wrote: Hi Brandon! Back to the original email .... Brandon Armstead schrieb: Hello guys, Is there a method upon using lookup("location") to also pull out the "socket" information for the original location the UAC registered to, for scenarios of this example: P1 & P2 share same usrloc database. UA1 registers to P1 UA2 registers to P2 UA1 calls UA2 UA1 invites -> P1 -> INVITES -> UA2 (bypassing P2 -- where the actual nat binding is). Now upon P1 looking up usrloc for UA2, I would like to recognize that P1 is not the Proxy to deliver the call, and forward the request to P2 to send to UA2. So currently I have: UA1 INVITE -> P1 INVITE -> UA2 I wish to have: UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2 Is there an easy method to do this? I have been looking at the new nat traversal module it looks like it is doable with this (any further input as far as that?). Also is it possible with the classic Nat Helper module? Any input is appreciated, thanks! I think the nat_traversal module can not help you in this case, nor nathelper. One possibility would be to spoof at P1 the IP address of P2 - nevertheless this would cause the reply sent back to P2, but the transaction is created in P1. (and you need to hack Kamailio for IP spoofing). Another easy solution would be: In P1 set a certain branch-flag when the client registers, e.g. bflag 1. In P2 set a certain branch-flag when the client registers, e.g. bflag 2. Now, if a user is called, just make a lookup() and t_relay. Further in the branch_route check if: in P1: isbflagset(2) --> forward to P2 in P2: isbflagset(1) --> forward to P1 klaus ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla http://www.asipto.com/ -- Daniel-Constantin Mierla http://www.asipto.com/ -- Daniel-Constantin Mierla http://www.asipto.com/ ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla http://www.asipto.com/
--
Daniel-Constantin Mierla
http://www.asipto.com/
1 May
1 May
10:19 p.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Daniel,
I got this part working, in the case of the absence of $du (i.e. no received parameter) I just exclude it and all works well! Thanks guys!
* fixed reply to all.
On Thu, Apr 30, 2009 at 1:16 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hello,
On 04/29/2009 08:35 PM, Brandon Armstead wrote:
Daniel,
You are correct it is not set for this usrloc. Should I be able to just not modify $du in this case?
I do not understand what you mean now?!?!
Cheers, Daniel
Thanks!
On Wed, Apr 29, 2009 at 7:39 AM, Daniel-Constantin Mierla < miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
$du is set by usrloc only if there is a received value in the location record. Can you check if you have it in db?
Cheers, Daniel
On 04/29/2009 11:45 AM, Brandon Armstead wrote:
Daniel, Yes I'm doing an append_hf("X-Duri: $du\r\n"); inside of branch_route[] i.e.: branch_route[2] { if(isbflagset(4)){ # thats me! } else { # at this point X-Duri is null, so we are not saving it from the lookup? # we need to save this to pass onto Proxy B, however the value is NULL at this point, and at the point of Proxy B (when received). append_hf("X-Duri: $avp(s:duri)\r\n"); if(isbflagset(6)){ $du = "sip:PROXY_B;transport=udp;"; } } xlog("L_INFO", "[$ci][branch_route][$T_branch_idx] ru=$ru fu=$fu tu=$tu si=$si flag=$bF du=$du"); } Then when X-Duri reaches Proxy B, if I see the INVITE comes from Proxy A, I take X-Duri and restore "$du" with the correct value. However this is causing issues now as the value is <null>, I've tried saving $du into avp after looking up usrloc, I've tried simply calling $du in branch_route[], and I've tried saving $du in loose_route() into an avp, all to no avail. What am I missing here as far as passing the value of $du from branch route to header, to pass along to Proxy B. Thanks again! On Wed, Apr 29, 2009 at 2:42 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> wrote: On 04/29/2009 11:32 AM, Brandon Armstead wrote: Daniel, It looks like you helped me find part of the problem, apparently Proxy A was sharing same branch flag as the one I used to distinguish which proxy it was. I corrected this and now branch flag for branch 1 is 00000060, and branch 2 is 00000040, however now both branches are routed appropriately to the correct server, however the X-Duri (to restore to in the INVITE) is null. I may not followed all discussion branch - the X-Duri is a header you append to the message? If yes, it is not visible immediately in the script, but you can see it when the messages is ent to the network. Do I need to save this value into an AVP after lookup("location")? What you need to do with it? Where is its values taken from? Cheers, Daniel Or should it be readily available in branch_route[], and for some reason my variable is null? P.S. (recap) Proxy A NAT Branch Flag: 5 Proxy B NAT Branch Flag: 5 (Problem existed as used Flag 5 to distinguish "itself" as proxy) -- changed this to 4 so now: Proxy A NAT Branch Flag: 4 Proxy B NAT Branch Flag: 6 Calls are routed to Proxy B X-Duri: <null> (as it is null in Proxy A). I'm append_hf(X-Duri: $du) inside of branch_route[]. Thanks! On Wed, Apr 29, 2009 at 2:17 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>> wrote: On 04/29/2009 11:11 AM, Brandon Armstead wrote: Daniel, No that would be the UAC (I have two clients behind the same NAT). The problem is it looks like the branch flag is not being set for both for some reason (when comparing) even though in the database it is the same? So you have the brach flag for nat and branch flags for next proxy, right? What is the value of branch flag? The value are different indeed, but some flags you are looking for might be set. It is easier spot if you print the hexa format of the flags rather than decimal one. Cheers, Daniel Take a look at the flag= value from each of those logs (this is one call) to a UAC with two registrations line1/line2. On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>>> wrote: Hello, On 04/29/2009 10:53 AM, Brandon Armstead wrote: Hey guys, Still facing a few challenges and seeing if any further input, I'm specifically trying inaki's suggestions / method, but here are the current problems: sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>>][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.com<sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com><mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com><mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com> <mailto:sip%252525253ACALLER@sip.example.com<sip%25252525253ACALLER@sip.example.com>>
tu=sip:CALLEE@sip.example.com<sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com><mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com><mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com> <mailto:sip%252525253ACALLEE@sip.example.com<sip%25252525253ACALLEE@sip.example.com>>>>>>si=99.XX.XX.XX
flag=96 du=<null> This call is not sent to Proxy B (this is a result of bflag not being set) ??? is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the address of that proxy. It is null in the log above. Cheers, Daniel My question is "Why", I look at the AOR / usrloc and they both have the "same exact flags set", this call is rather sent directly to UAC endpoint. --- Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>>][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.com<sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com><mailto:sip%3ACALLER@sip.example.com<sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com><mailto:sip%253ACALLER@sip.example.com<sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com><mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com><mailto:sip%25253ACALLER@sip.example.com<sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com><mailto:sip%2525253ACALLER@sip.example.com<sip%252525253ACALLER@sip.example.com> <mailto:sip%252525253ACALLER@sip.example.com<sip%25252525253ACALLER@sip.example.com>>
tu=sip:CALLEE@sip.example.com<sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com><mailto:sip%3ACALLEE@sip.example.com<sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com><mailto:sip%253ACALLEE@sip.example.com<sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com><mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com><mailto:sip%25253ACALLEE@sip.example.com<sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com><mailto:sip%2525253ACALLEE@sip.example.com<sip%252525253ACALLEE@sip.example.com> <mailto:sip%252525253ACALLEE@sip.example.com<sip%25252525253ACALLEE@sip.example.com>>>>>>si=99.XX.XX.XX
flag=64 du=sip:PROXY_B;transport=udp; This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp? Again, thank you for all and any help, thanks! On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead <brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>>>> wrote: Klaus, Inaki, Daniel, Thanks! Sorry I did not see this email come through, I'm going to go ahead and give this method a go, and I'll update with the results, I have optimistic views. As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help! Sincerely, Brandon. On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>>> wrote: Brandon Armstead schrieb: Klaus, So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call: if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; } 1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly. 2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER. 3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy. Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client). e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V VP3---->Bob3 Bob1
Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3. So, P1 is the originating proxy. P2 is the serving proxy of Bob2. .... We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only. route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); } # downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); } t_on_reply("1"); t_relay(); exit(); } ... # I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; } ... # a new request - thus I am the originating proxy if ($dU looks like phone number) { ... route to Gateway.... exit; } if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1"); # activate reply route to activate RTP proxy t_on_reply("1"); # NAT traversal fix_nated_contact(); record_route(); t_relay(); exit; } branch_route[1]{ if(isbflagset(1)){ # oh, that's me # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both"); # add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes"); force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller"); # we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } } reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } } Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port. regards klaus On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as: [INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?) Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be? I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks! On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> <mailto:klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at <mailto: klaus.mailinglists@pernau.at
...
[Message clipped]
2 May
2 May
9:35 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Hello,
On 05/02/2009 12:19 AM, Brandon Armstead wrote:
Daniel,
I got this part working, in the case of the absence of $du (i.e.no received parameter) I just exclude it and all works well!
ok. $du is special field that is mostly internally by several modules, e.g., rr, dispatcher or usrloc. It is not present all the time.
Cheers, Daniel
Thanks guys!
- fixed reply to all.
On Thu, Apr 30, 2009 at 1:16 AM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, On 04/29/2009 08:35 PM, Brandon Armstead wrote: Daniel, You are correct it is not set for this usrloc. Should I be able to just not modify $du in this case? I do not understand what you mean now?!?! Cheers, Daniel Thanks! On Wed, Apr 29, 2009 at 7:39 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> wrote: Hello, $du is set by usrloc only if there is a received value in the location record. Can you check if you have it in db? Cheers, Daniel On 04/29/2009 11:45 AM, Brandon Armstead wrote: Daniel, Yes I'm doing an append_hf("X-Duri: $du\r\n"); inside of branch_route[] i.e.: branch_route[2] { if(isbflagset(4)){ # thats me! } else { # at this point X-Duri is null, so we are not saving it from the lookup? # we need to save this to pass onto Proxy B, however the value is NULL at this point, and at the point of Proxy B (when received). append_hf("X-Duri: $avp(s:duri)\r\n"); if(isbflagset(6)){ $du = "sip:PROXY_B;transport=udp;"; } } xlog("L_INFO", "[$ci][branch_route][$T_branch_idx] ru=$ru fu=$fu tu=$tu si=$si flag=$bF du=$du"); } Then when X-Duri reaches Proxy B, if I see the INVITE comes from Proxy A, I take X-Duri and restore "$du" with the correct value. However this is causing issues now as the value is <null>, I've tried saving $du into avp after looking up usrloc, I've tried simply calling $du in branch_route[], and I've tried saving $du in loose_route() into an avp, all to no avail. What am I missing here as far as passing the value of $du from branch route to header, to pass along to Proxy B. Thanks again! On Wed, Apr 29, 2009 at 2:42 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>> wrote: On 04/29/2009 11:32 AM, Brandon Armstead wrote: Daniel, It looks like you helped me find part of the problem, apparently Proxy A was sharing same branch flag as the one I used to distinguish which proxy it was. I corrected this and now branch flag for branch 1 is 00000060, and branch 2 is 00000040, however now both branches are routed appropriately to the correct server, however the X-Duri (to restore to in the INVITE) is null. I may not followed all discussion branch - the X-Duri is a header you append to the message? If yes, it is not visible immediately in the script, but you can see it when the messages is ent to the network. Do I need to save this value into an AVP after lookup("location")? What you need to do with it? Where is its values taken from? Cheers, Daniel Or should it be readily available in branch_route[], and for some reason my variable is null? P.S. (recap) Proxy A NAT Branch Flag: 5 Proxy B NAT Branch Flag: 5 (Problem existed as used Flag 5 to distinguish "itself" as proxy) -- changed this to 4 so now: Proxy A NAT Branch Flag: 4 Proxy B NAT Branch Flag: 6 Calls are routed to Proxy B X-Duri: <null> (as it is null in Proxy A). I'm append_hf(X-Duri: $du) inside of branch_route[]. Thanks! On Wed, Apr 29, 2009 at 2:17 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>>> wrote: On 04/29/2009 11:11 AM, Brandon Armstead wrote: Daniel, No that would be the UAC (I have two clients behind the same NAT). The problem is it looks like the branch flag is not being set for both for some reason (when comparing) even though in the database it is the same? So you have the brach flag for nat and branch flags for next proxy, right? What is the value of branch flag? The value are different indeed, but some flags you are looking for might be set. It is easier spot if you print the hexa format of the flags rather than decimal one. Cheers, Daniel Take a look at the flag= value from each of those logs (this is one call) to a UAC with two registrations line1/line2. On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>> <mailto:miconda@gmail.com <mailto:miconda@gmail.com> <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>>>> wrote: Hello, On 04/29/2009 10:53 AM, Brandon Armstead wrote: Hey guys, Still facing a few challenges and seeing if any further input, I'm specifically trying inaki's suggestions / method, but here are the current problems: sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep -v -E 'non-local|repeated' | grep branch_route Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>>>][branch_route][1] ru=sip:CALLEE@99.XX.XX.XX:5079 fu=sip:CALLER@sip.example.com <mailto:sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com>>>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com>>>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com>>> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com>> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com> <mailto:sip%252525253ACALLER@sip.example.com <mailto:sip%25252525253ACALLER@sip.example.com>>>>>> tu=sip:CALLEE@sip.example.com <mailto:sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com>>>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com>>>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com>>> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com>> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com> <mailto:sip%252525253ACALLEE@sip.example.com <mailto:sip%25252525253ACALLEE@sip.example.com>>>>>> si=99.XX.XX.XX flag=96 du=<null> This call is not sent to Proxy B (this is a result of bflag not being set) ??? is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the address of that proxy. It is null in the log above. Cheers, Daniel My question is "Why", I look at the AOR / usrloc and they both have the "same exact flags set", this call is rather sent directly to UAC endpoint. --- Apr 29 07:38:05 db06 /sbin/kamailio[21279]: [77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35> <mailto:77e4c600-147767fb@172.16.1.35 <mailto:77e4c600-147767fb@172.16.1.35>>>>>>][branch_route][2] ru=sip:CALLEE@99.XX.XX.XX:5062 fu=sip:CALLER@sip.example.com <mailto:sip%3ACALLER@sip.example.com> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com>>>>> <mailto:sip%3ACALLER@sip.example.com <mailto:sip%253ACALLER@sip.example.com> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com>>>> <mailto:sip%253ACALLER@sip.example.com <mailto:sip%25253ACALLER@sip.example.com> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com>> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com>>> <mailto:sip%25253ACALLER@sip.example.com <mailto:sip%2525253ACALLER@sip.example.com> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com>> <mailto:sip%2525253ACALLER@sip.example.com <mailto:sip%252525253ACALLER@sip.example.com> <mailto:sip%252525253ACALLER@sip.example.com <mailto:sip%25252525253ACALLER@sip.example.com>>>>>> tu=sip:CALLEE@sip.example.com <mailto:sip%3ACALLEE@sip.example.com> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com>>>>> <mailto:sip%3ACALLEE@sip.example.com <mailto:sip%253ACALLEE@sip.example.com> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com>>>> <mailto:sip%253ACALLEE@sip.example.com <mailto:sip%25253ACALLEE@sip.example.com> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com>> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com>>> <mailto:sip%25253ACALLEE@sip.example.com <mailto:sip%2525253ACALLEE@sip.example.com> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com>> <mailto:sip%2525253ACALLEE@sip.example.com <mailto:sip%252525253ACALLEE@sip.example.com> <mailto:sip%252525253ACALLEE@sip.example.com <mailto:sip%25252525253ACALLEE@sip.example.com>>>>>> si=99.XX.XX.XX flag=64 du=sip:PROXY_B;transport=udp; This call is sent to Proxy B (however Proxy B) - however the X-Duri (is null) as it is not existant in Proxy A's branch route? should I save this from right after the lookup("location") result into an avp? Again, thank you for all and any help, thanks! On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead <brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>> <mailto:brandon@cryy.com <mailto:brandon@cryy.com> <mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>>>>> wrote: Klaus, Inaki, Daniel, Thanks! Sorry I did not see this email come through, I'm going to go ahead and give this method a go, and I'll update with the results, I have optimistic views. As for the reason I was rewriting $ru and setting $du to null, is because originally when I just changed $du to the 'destination proxy' it did not seem to work at all (I do not even recall what exactly what was happening) however I decided to just change $ru, and have the other proxy just "lookup" the usrloc information again. Again, this method looks interesting and I'll let you guys know how it goes, thanks for all the input and help! Sincerely, Brandon. On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>>>> wrote: Brandon Armstead schrieb: Klaus, So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call: if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; } 1. The above code has to be in the branch_route block - otherwise multiple registrations of a single user are not handled correctly. 2. you are rewriting the RURI. You should not do that as some clients wants to the in the RURI the Contact provided during REGISTER. 3. probably you use fix_nated_register() to store the public IP:port of the client too. After lookup, this information is written to DURI. Thus, by setting $du you overwrite this info. You should put it into a special header so that you can restore it in the other proxy. Here a snippet how it should work (untested, no warranty): ( I use the term "originating" proxy for the proxy which received the INVITE and the term "serving" proxy for the proxy which handles the connection/registration of a certain SIP client). e.g: Alice -----INVITE-----> P1------->P2----->Bob2 / \ / \ / V V P3---->Bob3 Bob1 Bob's client Bob1 is connected to P1. Bob's client Bob2 is connected to P2. Bob's client Bob3 is connected to P3. So, P1 is the originating proxy. P2 is the serving proxy of Bob2. .... We do NAT traversal (note: we must not call fix_nated_contact() for messages sent between the proxies!): the originating proxy for the call-leg to the caller, the serving proxy for the call-leg to the callee. The RTP proxy will be managed by the originating proxy only. route{ if (loose_route()) { ... additional loose route processing... if (check_route_param("rtpproxy=yes")) { force_rtp_proxy(); setbflag(7); } # downstream: in-dialog request is in the same direction as the # initial request if ( (check_route_param("nat=caller") && is_direction("downstream")) || (check_route_param("nat=callee") && is_direction("upstream"))) { fix_nated_contact(); } else if (check_route_param("nat=both") { fix_nated_contact(); setbflag(8); } else { setbflag(8); } t_on_reply("1"); t_relay(); exit(); } ... # I am proxy 1 if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) { # request comes from other proxy, that means I am the # serving proxy # do not lookup(), RURI is already set and # DURI is provided in our X-DURI header $du = $header(X-DURI); # we do not care about an RTP proxy because that's the task of the # proxy which performed the lookup() (the originating proxy) # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee add_rr_param(";nat=callee"); # activate reply_route to fix_nated_contact of callee setbflag(8); # flag 8 = fix contact t_on_reply("1"); record_route(); t_relay(); exit; } ... # a new request - thus I am the originating proxy if ($dU looks like phone number) { ... route to Gateway.... exit; } if (!lookup("location")) { sl_send_reply("404","not found"); exit; } # activate branch route to have dedicated routing per branch t_on_branch("1"); # activate reply route to activate RTP proxy t_on_reply("1"); # NAT traversal fix_nated_contact(); record_route(); t_relay(); exit; } branch_route[1]{ if(isbflagset(1)){ # oh, that's me # add some record-route cookie to mark that we should perform # SIP NAT traversal for the callee and caller add_rr_param(";nat=both"); # add some record-route cookie to mark that we are # in charge for the RTP proxy add_rr_param(";rtpproxy=yes"); force_rtp_proxy(); setbflag(7); # flag 7 = RTP proxy } else { # add some record-route cookie to mark that we should perform # SIP NAT traversal for the caller add_rr_param(";nat=caller"); # we have to route the request to the serving proxy # write DURI in the header append_hf("X-DURI: $du"); if(isbflagset(2)){ $du = sip:ip.of.proxy.2;transport=udp; } else if(isbflagset(3)){ $du = sip:ip.of.proxy.3;transport=udp; } else if(isbflagset(4)){ $du = sip:ip.of.proxy.4;transport=udp; } } } reply_route[1]{ if (isbflagset(7) && has_body("application/sdp")) { force_rtp_proxy() } if (isbflagset(8)) { fix_nated_contact() } } Note: this code does not care about the received socket of the proxy. Thus it works if the proxy listens only on one port. regards klaus On each Proxy, I changed the code appropriately excluding the Proxy from itself (so it does not forward to itself). I'm noticing weird behavior however as it seems as if what is happening is it created other issues such as: [INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?) Also I setup this test amongst two development servers (in which case it worked without issues). Once I included in more development instances into the ring it seemed as if the flags were being set when they should not be? I.e. I placed a call FROM UA1 (with bflag 5 SET) From the above example configuration ^ code. If you notice (flag 5) is missing. To UA2 (Flag 3), again this looked to be doing some strange things such as acting as if another flag was set when it should not have been, thus forwarding to the wrong proxy or the wrong proxy order. Do you guys have any further thoughts or input on this? Thanks! On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion <klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>>>>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at>> <mailto:klaus.mailinglists@pernau.at <mailto:klaus.mailinglists@pernau.at> <mailto: ... [Message clipped]
--
Daniel-Constantin Mierla
http://www.asipto.com/
24 Apr
24 Apr
8:23 a.m.
New subject: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
2009/4/23 Brandon Armstead brandon@cryy.com:
So I took you and Inaki's input and essentially constructed a setup like so after the lookup("location") call:
if(isbflagset(1)){ $du = null; $rd = "P1"; } else if(isbflagset(2)){ $du = null; $rd = "P2"; } else if(isbflagset(3)){ $du = null; $rd = "P3"; } else if(isbflagset(4)){ $du = null; $rd = "P4"; }
Brandon, please re-read my previous mail in which I suggested rewritting $du (never $ru).
--
Iñaki Baz Castillo
ibc@aliax.net
5774
Age (days ago)
5785
Last active (days ago)
23 comments
4 participants
participants (4)
-
Brandon Armstead -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion