[Serusers] Need help with Record-Route

[Jiri Kuthan]

Make sure your SER script includes route-processing, as in SER's
default config file in beginning. E.g, like

    # subsequent messages withing a dialog should take the
    # path determined by record-routing
    if (loose_route()) {
        # mark routing logic in request
        append_hf("P-hint: rr-enforced\r\n");
        route(1);
        break;
    };


-jiri

At 10:23 PM 11/19/2003, Garey, Tim wrote:
>I am using ser 0.8.11 with redhat 9. I am not using mysql or authentication 
>and currently have a pretty simple config due to my limited programming
>skills.
>I have orig phone A registered to SER and have SER rewriting A's INVITES so
>our 
>softswitch will be happy. Terminating phone B is registered to our
>softswitch.
>
>Phone A can call a phone B and 2 way voice is established. Phone B can 
>terminate the call and the session will end. All is ok until I try and
>use Record-Route (by removing comment #) in my ser.cfg below.
>
>Using Record-Route, when the terminating phone answers, the 200 OK
>will propagate all the way through SER and to the originating phone but
>at this point the ACK will not get sent back by SER. Because of
>this our softswitch will continue to send the 200 OK and after some time
>it gives up and terminates both legs with BYE's. Please reference the
>attached sip_scenario trace file (which has end packets removed to conserve
>space)
>
>Could someone suggest how I might use Record-Route properly?
>
>Thanks in advance!
>
>Tim
>=========================================
>
>(10.16.1.218) is SER registered phone who initiates call
>10.16.1.147 is SER
>172.17.4.102 is our softswitch acting as back2back user agent.
>(10.16.1.214) is softswitch registered phone answers/terminates call.
>================================================
>Here is routing logic:
>
># main routing logic
>
>route{
>
>        # initial sanity checks -- messages with
>        # max_forwards==0, or excessively long requests
>        if (!mf_process_maxfwd_header("10")) {
>                sl_send_reply("483","Too Many Hops");
>                break;
>        };
>        if (len_gt( max_len )) {
>                sl_send_reply("513", "Message too big");
>                break;
>        };
>
>        if (method=="INVITE") {
>                rewritehostport("172.17.4.102");
>        #       record_route();
>                t_relay();
>        #       forward (172.17.4.102, 5060);
>        };
>
>        # we record-route all messages -- to make sure that
>        # subsequent messages will go through our proxy; that's
>        # particularly good if upstream and downstream entities
>        # use different transport protocol
>        #record_route();        
>        # loose-route processing
>        #if (loose_route()) {
>        #       t_relay();
>        #       break;
>        #};
>
>        # if the request is for other domain use UsrLoc
>        # (in case, it does not work, use the following command
>        # with proper names and addresses in it)
>        if (uri==myself) {
>
>                if (method=="REGISTER") {
>
># Uncomment this if you want to use digest authentication
>#                       if (!www_authorize("iptel.org", "subscriber")) {
>#                               www_challenge("iptel.org", "0");
>#                               break;
>#                       };
>
>                        save("location");
>                        break;
>                };
>
>                # native SIP destinations are handled using our USRLOC DB
>                if (!lookup("location")) {
>                        sl_send_reply("404", "Not Found");
>                        break;
>                };
>        };
>        # forward to current uri now; use stateful forwarding; that
>        # works reliably even if we forward from TCP to UDP
>        #if (!t_relay()) {
>        #       sl_reply_error();
>        #};
>
>}
>
> <<test3.txt>> 
>
>
>
>
>
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers

--
Jiri Kuthan            http://iptel.org/~jiri/