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
> <mico...@gmail.com <mailto:mico...@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
> <mico...@gmail.com <mailto:mico...@gmail.com>
> <mailto:mico...@gmail.com <mailto:mico...@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
> <mico...@gmail.com <mailto:mico...@gmail.com>
> <mailto:mico...@gmail.com <mailto:mico...@gmail.com>>
> <mailto:mico...@gmail.com <mailto:mico...@gmail.com>
> <mailto:mico...@gmail.com <mailto:mico...@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-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>>>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>>>>][branch_route][1]
> ru=sip:cal...@99.xx.xx.xx:5079
> fu=sip:cal...@sip.example.com
> <mailto:sip%3acal...@sip.example.com>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>>>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>
> <mailto:sip%25253acal...@sip.example.com
> <mailto:sip%2525253acal...@sip.example.com>>>>
>
>
> tu=sip:cal...@sip.example.com
> <mailto:sip%3acal...@sip.example.com>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>>>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>
> <mailto:sip%25253acal...@sip.example.com
> <mailto:sip%2525253acal...@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-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>>>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>
> <mailto:77e4c600-14776...@172.16.1.35
> <mailto:77e4c600-14776...@172.16.1.35>>>>][branch_route][2]
> ru=sip:cal...@99.xx.xx.xx:5062
> fu=sip:cal...@sip.example.com
> <mailto:sip%3acal...@sip.example.com>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>>>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>
> <mailto:sip%25253acal...@sip.example.com
> <mailto:sip%2525253acal...@sip.example.com>>>>
>
>
> tu=sip:cal...@sip.example.com
> <mailto:sip%3acal...@sip.example.com>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>>>
> <mailto:sip%3acal...@sip.example.com
> <mailto:sip%253acal...@sip.example.com>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>>
> <mailto:sip%253acal...@sip.example.com
> <mailto:sip%25253acal...@sip.example.com>
> <mailto:sip%25253acal...@sip.example.com
> <mailto:sip%2525253acal...@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
> <bran...@cryy.com <mailto:bran...@cryy.com>
> <mailto:bran...@cryy.com <mailto:bran...@cryy.com>>
> <mailto:bran...@cryy.com <mailto:bran...@cryy.com>
> <mailto:bran...@cryy.com <mailto:bran...@cryy.com>>>
> <mailto:bran...@cryy.com
> <mailto:bran...@cryy.com> <mailto:bran...@cryy.com
> <mailto:bran...@cryy.com>>
> <mailto:bran...@cryy.com <mailto:bran...@cryy.com>
> <mailto:bran...@cryy.com <mailto:bran...@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.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>>>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@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.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>>>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>>>>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>>>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@pernau.at>
> <mailto:klaus.mailingli...@pernau.at
> <mailto:klaus.mailingli...@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/
_______________________________________________
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
