Simple B2BUA top hiding config

2010-05-05
2013-05-09
  • Pavel Despot
    Pavel Despot
    2010-05-05

    Hello, all.

    I'm trying to get a simple topolgy hiding configuration working but I seem to be missing something.  When I run wireshark, I don't see anything leave the machine on which I have opensips running nor does it respond to the Invite. 

    I've loaded the b2b_logic and b2b_entities module, added modparam("b2b_entities", "server_address", "sip:sa@10.100.100.65:5060"), and added modparam("tm", "pass_provisional_replies", 1).

    "top hiding" is mentioned here - http://www.opensips.org/Resources/B2buaTutorial16 but it's not in the example config - http://www.opensips.org/Resources/B2bConfigExample.

    Logically, I think the problem is that I'm missing the config item that tells the system where to send the Invite, but I can't find anywhere that says how I would do that in conjunction with b2b_init("top hiding") - versus using a script or extern scenario.

    This is my current routing logic section:

    # main request routing logic

    route{

            if (!mf_process_maxfwd_header("10")) {
                    sl_send_reply("483","Too Many Hops");
                    exit;
            }

            if(method=="INVITE")
            {
                    b2b_init_request("top hiding");
                    exit;
            }
            route(1);

    }

    route {

            if (!t_relay())
            {
                    sl_reply_error();
            };
            exit;
    }

    Any help is VERY much appreciated.

    Regards.

     
  • Anca Vamanu
    Anca Vamanu
    2010-05-06

    Buna Pavel,

    What you put in your config should be enough for b2b tophiding to work. I suggest raising the debug level in your configuration file 'debug=6' and check if there are any errors when b2b processes the Invite.

    Regards,
    Anca

     
  • Pavel Despot
    Pavel Despot
    2010-05-06

    Hi, Anca.  Thanks for the reply.

    First, maybe it's worth briefly describing the setup…

    I have a UAC that normally talks to an AudioCodes gateway, and I'm trying to put OpenSIPS in between the two as a B2BUA.  So it looks something like this:

    UAC (10.100.100.82) <-> OpenSIPS (10.100.100.65) <-> AudioCodes (10.100.100.101)

    When I run wireshark on the OpenSIPS server, I see an INVITEfrom .82 to .65 and a Trying from .65 back to .82.  So that's good.  But then, I don't see anything else go in either direction.

    In the debug, I see the INVITE come in.
    May  6 13:03:11  DBG:core:parse_msg: SIP Request:
    May  6 13:03:11  DBG:core:parse_msg:  method:  <INVITE>
    May  6 13:03:11  DBG:core:parse_msg:  uri:     <sip:xxxxxxxxxx@10.100.100.65:5060;user=phone>
    May  6 13:03:11  DBG:core:parse_msg:  version: <SIP/2.0>
    May  6 13:03:11  DBG:core:parse_headers: flags=2
    May  6 13:03:11  DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK48af838c>; state=6
    May  6 13:03:11  DBG:core:parse_via_param: found param type 235, <rport> = <n/a>; state=17
    May  6 13:03:11  DBG:core:parse_via: end of header reached, state=5
    May  6 13:03:11  DBG:core:parse_headers: via found, flags=2
    May  6 13:03:11  DBG:core:parse_headers: this is the first via
    May  6 13:03:11  DBG:core:receive_msg: After parse_msg…
    May  6 13:03:11  DBG:core:receive_msg: preparing to run routing scripts…
    May  6 13:03:11  DBG:core:parse_headers: flags=ffffffffffffffff
    May  6 13:03:11  DBG:core:parse_to: end of header reached, state=10
    May  6 13:03:11  DBG:core:parse_to: display={}, ruri={sip:xxxxxxxxxx@10.100.100.65:5060;user=phone}
    May  6 13:03:11  DBG:core:get_hdr_field: <To> ; uri=
    May  6 13:03:11  DBG:core:get_hdr_field: to body
    May  6 13:03:11  DBG:core:get_hdr_field: cseq <CSeq>: <1> <INVITE>
    May  6 13:03:11  DBG:core:get_hdr_field: content_length=268
    May  6 13:03:11  DBG:core:get_hdr_field: found end of header
    May  6 13:03:11  DBG:b2b_entities:b2b_prescript_f: start - method = INVITE
    etc…

    Immediately thereafter, I see what appears to be the same message come back in…
    May  6 13:03:11  DBG:core:parse_msg: SIP Request:
    May  6 13:03:11  DBG:core:parse_msg:  method:  <INVITE>
    May  6 13:03:11  DBG:core:parse_msg:  uri:     <sip:xxxxxxxxxx@10.100.100.65:5060>
    May  6 13:03:11  DBG:core:parse_msg:  version: <SIP/2.0>
    May  6 13:03:11  DBG:core:parse_headers: flags=2
    May  6 13:03:11  DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKa045.c690bb22.0>; state=16
    May  6 13:03:11  DBG:core:parse_via: end of header reached, state=5
    May  6 13:03:11  DBG:core:parse_headers: via found, flags=2
    May  6 13:03:11  DBG:core:parse_headers: this is the first via
    May  6 13:03:11  DBG:core:receive_msg: After parse_msg…
    May  6 13:03:11  DBG:core:receive_msg: preparing to run routing scripts…
    May  6 13:03:11  DBG:core:parse_headers: flags=ffffffffffffffff
    May  6 13:03:11  DBG:core:parse_to: end of header reached, state=9
    May  6 13:03:11  DBG:core:parse_to: display={}, ruri={sip:xxxxxxxxxx@10.100.100.65:5060}
    May  6 13:03:11  DBG:core:get_hdr_field: <To> ; uri=
    May  6 13:03:11  DBG:core:get_hdr_field: to body
    May  6 13:03:11  DBG:core:get_hdr_field: cseq <CSeq>: <2> <INVITE>
    May  6 13:03:11  DBG:core:get_hdr_field: content_length=268
    May  6 13:03:11  DBG:core:get_hdr_field: found end of header
    May  6 13:03:11  DBG:b2b_entities:b2b_prescript_f: start - method = INVITE

    This pattern repeat 2469 times (judging by the CSeq header which seems to increment with each INVITE).

    After which I see the following:
    May  6 13:03:20  CRITICAL:core:receive_fd: EOF on 15
    May  6 13:03:20  DBG:core:handle_ser_child: dead child 8, pid 7225 (shutting down?)
    May  6 13:03:20  DBG:core:io_watch_del: io_watch_del (0x8181f00, 15, -1, 0x0) fd_no=22 called
    May  6 13:03:20  INFO:core:handle_sigs: child process 7225 exited by a signal 11
    May  6 13:03:20  INFO:core:handle_sigs: core was generated
    May  6 13:03:20  INFO:core:handle_sigs: terminating due to SIGCHLD
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  INFO:core:sig_usr: signal 15 received
    May  6 13:03:20  DBG:b2b_logic:b2bl_delete: Delete record, hash_index=, local_index=
    May  6 13:03:20  DBG:b2b_logic:b2bl_delete: pointer
    May  6 13:03:20  DBG:b2b_entities:b2b_parse_key: hash_index =   - local_index=
    May  6 13:03:20  DBG:b2b_entities:b2b_entity_delete: Deleted B2B.21.176
    May  6 13:03:20  DBG:b2b_entities:b2b_search_htable_dlg: Complete match for the server dialog 0xb60afdd8!
    May  6 13:03:20  DBG:b2b_entities:b2b_parse_key: hash_index =   - local_index=
    May  6 13:03:20  DBG:b2b_entities:b2b_entity_delete: Deleted B2B.74.5631358
    May  6 13:03:20  DBG:b2b_entities:b2b_search_htable_dlg: dialog totag = 543fb38ad78b0f54d22d47edc420ea1a
    May  6 13:03:20  DBG:b2b_entities:b2b_search_htable_dlg: Found match

    gdb backtrace shows:
    (gdb) bt
    #0  0x00673402 in __kernel_vsyscall ()
    #1  0x00138df0 in raise () from /lib/libc.so.6
    #2  0x0013a701 in abort () from /lib/libc.so.6
    #3  0x0806b880 in sig_alarm_abort (signo=14) at main.c:426
    #4  <signal handler called>
    #5  0x080eae22 in fm_status (qm=0xb5f20000) at mem/f_malloc.c:607
    #6  0x0806b557 in cleanup (show_status=1) at main.c:367
    #7  0x0806c0c4 in handle_sigs () at main.c:533
    #8  0x08070654 in main (argc=4, argv=0xbf8c3974) at main.c:913

    My guess is that I'm missing something in the config to tell OpenSIPS to forward the INVITE to the .101 machine so, as a result, it's just looking at the Request URI and sending itself the message until it cores.

    Thanks again for the help.

    -Pavel

     
  • Ben
    Ben
    2010-05-06

    Hello,

    you just should try with record_route() and the forward() function :

      if (method=="INVITE") {
                    record_route();
    }

    and :

    forward("10.100.100.101");

    Just look at my post on May 03 2010 without the engage_mediaproxy() function (you don't want to relay RTP via mediaproxy, do you ?

    Ben

     
  • Anca Vamanu
    Anca Vamanu
    2010-05-07

    Hi Pavel,

    You seem to have found the problem, so why don't you know the solution? The Invite generated by b2bua will be looped to the same machine .65 and will go through the script. And the way you have your script, b2b_init_request will be called on it. You don't want that, do you?
    The solution is very simple - put a filter (and if you would have looked closer in the configuration file example - you yourself gave a link to it)
        if( is_method("INVITE") && !(src_ip == "10.10.10.10" && src_port ==5060)) /* skip Invite messages generated by the server*/
       {
            b2b_init_request("top hiding");
           exit;
       }

      and you can call t_relay() or forward on it.

    Another solution is to change the ruri before calling b2b_init_request .

    Regards,
    Anca

     
  • Anca Vamanu
    Anca Vamanu
    2010-05-07

    a correction - in the if in there the src ip must be compared with the ip of your machine "10.100.100.65)".

     
  • Pavel Despot
    Pavel Despot
    2010-05-07

    Ben & Anca,

    Thank you both for the suggestions.  I got a call through using both approaches.  Now I just have to do a little more testing to see if I need a B2BUA or plain forwading setup.

    One thing I noticed in the B2BUA setup is that my AudioCodes is returning an RSeq in the 183 back to OpenSIPS, but OpenSIPS doesn't include that in the resulting PRACK.  Is RFC 3262 supported?

    Thanks again.  You guys have been great!

    -Pavel

     
  • Anca Vamanu
    Anca Vamanu
    2010-05-07

    Hi Pavel,

    Unfortunately, there is no way now to pass in b2bua the RSeq headers from 183 reply to PRACK.

    Anca

     
  • Pavel Despot
    Pavel Despot
    2010-05-07

    Ok.  Thanks for that as well!

     
  • Joe Zhou
    Joe Zhou
    2010-06-04

    I tried the similar setup but get error message saying the "From" field is invalid from the peer SIP server, the B2B module did rewrite the other headers correctly. Any help would be appreciated!

    The error "From" sent out from B2B is below, why the private ip address and @ showing up in the "tag"?

    From: <sip:2483412562@172.17.51.2>;tag=7c6f6680-c091328a-81a-23311ac@172.17.51.268d5b187-54e2-410a-bcfa-920383d3eec9-20611844

     
  • Joe Zhou
    Joe Zhou
    2010-06-04

    I found the "Record-Route" has the similar issue two, the originating party INVITE headers are normal, after pass B2B, the "@IP address of the originating party " got into the "From" and "Record-Route", any idea?

     
  • Pavel Despot
    Pavel Despot
    2010-06-04

    Hello, zhzhjoe.

    I believe one of your problems is the "@" in the tag.  I'm sure everyone will keep me honest here, but as I read RFC3261, the issue is:
    1) From        =  ( "From" / "f" ) HCOLON from-spec
    2) "from-spec" is "( name-addr / addr-spec ) *( SEMI from-param )"   What we're interested in here is the from-param.
    3) "from-param" is "from-param  =  tag-param / generic-param"
    4) "tag-param" is '"tag" EQUAL token'
    5) Finally, if you look at how a token is defined (top of page221) it's:
          token       =  1*(alphanum / "-" / "." / "!" / "%" / "*"
                         / "_" / "+" / "`" / "'" / "~" )

    "@" is defined as a separator (same page)
          separators  =  "(" / ")" / "<" / ">" / "@" /
                         "," / ";" / ":" / "\" / DQUOTE /
                         "/" / "" / "?" / "=" /
                         "{" / "}" / SP / HTAB

    That violates, if I'm not mistaken, what a FROM field is defined as.  That's why I think you're getting that error.  Can you try and remove it and see what happens?  I'd be curious to see if that does the trick.

    Good luck!

    -Pavel

     
  • Joe Zhou
    Joe Zhou
    2010-06-04

    here is the cfg file:

    route {
    if (!mf_process_maxfwd_header("10")) {
    sl_send_reply("483","Too Many Hops");
    exit;
    };

    if (msg:len >= 2380 ) {
    sl_send_reply("513", "Message too big");
    exit;
    };

    if (!is_method("REGISTER")) record_route();

    if(is_method("INVITE") && !(src_ip == "199.122.28.11" && src_port ==5060))
    #/* skip Invite messages generated by the server*/
    {
    b2b_init_request("top hiding");
    exit;
    }

    if (uri=~"^sip:1{9}@") {
            rewritehost("199.122.28.10");
    };

    if (uri=~"^sip:2483412562@") {
            rewritehost("172.17.51.2");
    };

    route(1);
    }

    route {
    if (!t_relay()) {
    sl_reply_error();
    };
    exit;
    }

     
  • Joe Zhou
    Joe Zhou
    2010-06-04

    Hi Pavel, thanks for the detailed explanation, I knew the tag format is wrong, but it was caused by the b2b_init_request, the originating party 172.17.51.2 does not have the @IP in the tag, but after b2b, the proxy will send out the tag with @IP, strange… I am new to Opensips, I knew UAC module can modify the "From" field, but it is not right, the b2b module should have taken care of it, shouldn't it?

     
  • Joe Zhou
    Joe Zhou
    2010-06-04

    BTW here is my topology:

    IP PBX ( 172.17.51.2 ) -> Opensips ( SBC 199.122.28.11 ) --> testing SIP Gateway ( 199.122.28.10; eventually it will be replaced by Verizon Peer SBC )

     
  • Joe Zhou
    Joe Zhou
    2010-06-04

    If I took the b2b_init_request out, everything is working fine except the Opensips just relay without acting topology hiding at all.

     
  • Pavel Despot
    Pavel Despot
    2010-06-04

    Interesting.  Which version are you using?  I ran into a somewhat similar problem with 1.6.x.  Then I tried the dev release and it worked.

     
  • Joe Zhou
    Joe Zhou
    2010-06-04

    Aha, I am using the 1.6.2. Is the dev version stable enough for big VoIP ISP inveronment?

    Thank you so much!

     
  • Pavel Despot
    Pavel Despot
    2010-06-04

    I'll leave that answer up to others.  I'm using it in a lab and it's working fine but it's not doing any real traffic.

     
  • Anca Vamanu
    Anca Vamanu
    2010-06-07

    Hi Joe,

    Indeed the problem with the '@' in the from header has been solved in the svn branch. There were really no changes in the topology hiding part of the b2bua so I think it should be safe for you to use the svn version instead of release1.6.2.

    Regards,
    Anca Vamanu
    www.voice-system.ro