drouting in EC2

2012-01-05
2013-05-09
  • Amos Shahar

    Amos Shahar - 2012-01-05

    I'm trying to have a working opensips cfg script for implemnting drouting in the amazon EC2 - that's means that the opensips server has local IP. I used elasic IPs so not it is like the server is on DMZ.
    My call flow is: a UAC with public IP calls to the opensips in the cloud which should route the call to a carrier with public IP outside of the cloude.
    My problem that opensips relay the ACK (of the 200 OK) according to the contact and not according to the route. I need it to  relay the ACK to the server that send the 200 K and not the GW behind it.

    I used the advertised_address="mypublicIP"
    and the following script
    ****************************************
    route{

              if (is_method("INVITE")) {
                    route(4);
              } else {
                    route(1);
              }
    }

    route {
            if (is_method("INVITE")) {
                    #t_on_branch("2");
                    #t_on_reply("2");
                    t_on_failure("4");
                    record_route_preset("myPubIP:5060");
            }
            if (!t_relay()) {
                    sl_reply_error();
            };
            exit;
    }

    route {
     
      xlog("route 4  ********************************************************* \n");
      if (!do_routing("0")) {
         send_reply("503", "No Rules matching the URI");
         exit;
      }
      if (is_method("INVITE")) {
         t_on_failure("4");
      }
       route(1);
    }
    failure_route {
        if (use_next_gw()) {
            t_relay();
            exit;
        } else {
            t_reply ("503", "Service not available");
            exit;
        }

    The SIP flow is blow :  you can see the problem is at line 8. opensips relays the ACK according to the contact and I need it to go accouding to the route to 213.137.55.147

      1 *** 213.137.99.138 -> 10.0.20.91   SIP/SDP Request: INVITE sip:8888@ec2-107-21-0-91.compute-1.amazonaws.com, with session description
      2 *** 10.0.20.91 -> 213.137.99.138 SIP Status: 100 Giving a try
      3 *** 10.0.20.91 -> 213.137.55.147 SIP/SDP Request: INVITE sip:8888@213.137.55.147, with session description
      4 *** 213.137.55.147 -> 10.0.20.91   SIP Status: 100 Trying
      5 *** 213.137.55.147 -> 10.0.20.91   SIP/SDP Status: 200 OK, with session description
      6 *** 10.0.20.91 -> 213.137.99.138 SIP/SDP Status: 200 OK, with session description
      7 *** 213.137.99.138 -> 10.0.20.91   SIP Request: ACK sip:8888@213.137.11.248:5060
      8 *** 10.0.20.91 -> 213.137.11.248 SIP Request: ACK sip:8888@213.137.11.248:5060
      9 *** 213.137.55.147 -> 10.0.20.91   SIP/SDP Status: 200 OK, with session description
      10 ** 10.0.20.91 -> 213.137.99.138 SIP/SDP Status: 200 OK, with session description
      11 ** 213.137.99.138 -> 10.0.20.91   SIP Request: ACK sip:8888@213.137.11.248:5060
      12 ** 10.0.20.91 -> 213.137.11.248 SIP Request: ACK sip:8888@213.137.11.248:5060
      13 ** 213.137.55.147 -> 10.0.20.91   SIP/SDP Status: 200 OK, with session description
      14 ** 10.0.20.91 -> 213.137.99.138 SIP/SDP Status: 200 OK, with session description

    the incoming ACK is:
        Request-Line: ACK sip:8888@213.137.11.248:5060 SIP/2.0
            Via: SIP/2.0/UDP 213.137.99.138:54608;branch=z9hG4bK-d8754z-f17d960342556d04-1--d8754z-
            Max-Forwards: 70
            Route: <sip:MyPublicIP:5060;lr>
            Route: <sip:8888@213.137.55.180:5060;maddr=213.137.55.147>
            Contact: <sip:1000@213.137.99.138:54608>
            To: "8888"<sip:8888@MyPubIP>;tag=BCCD928C-F23
            From: "2000"<sip:1000@MyPubIP>;tag=e06f6b42
            Call-ID: NGFkNzM1MDZhMGIwZWE0ODRhM2RkZWI3NjQ1ZjVkNTk.
            CSeq: 1 ACK
            User-Agent: X-Lite release 1104o stamp 56125
            Content-Length: 0

    Thanks,
    Amos

     
  • Bogdan-Andrei Iancu

    Hi Amos,

    the structure of your script is not correct as you handle in the same way the initial and in-dialog requests - normally you explicitly route only the initial requests (like INVITEs) and let the in-dialog requests to be driven by the RR-Route mechanism.

    To better understand this, see http://www.opensips.org/Resources/Webinars#toc11

    Regards,
    Bogdan