Greger Viken Teigre wrote: 
If you have alias=ip-of-ser in your config, ACK with port 5070 in ruri will match uri==myself.
The ACK should just be relayed.
See example cfg for ser used for sems for an example.
g-)
Unfortunately I am still quite puzzled by the SER configuration process, so I have not been able to work out exactly what to do. The ser/sems example uses pipes which doesn't help.

So far I have simply added a clause to always forward ACK packets. This is not sufficient.

The ACK gets through but now the BYE command gets rejected 404 not found on the user location lookup. I think this is caused by the aliases involved in the call ?

(Call is dialled as 2311@fesa.sto. It gets reformed to 1001@butler.fesa.sto and passed to the SER proxy for butler.fesa.sto. SER knows 1001 is an alias of registered user 1009 and sends the call to the user)

Here is a log of a call made on the SER machine butler.fesa.sto

 25.202593  10.50.32.10 -> 127.0.0.1    SIP Request: REGISTER sip:localhost.localdomain      <-- my application registering
 25.213719    127.0.0.1 -> 10.50.32.10  SIP Status: 200 OK    (1 bindings)
 75.234982   10.1.39.10 -> 10.50.32.10  SIP/SDP Request: INVITE sip:1001@butler.fesa.sto;transport=udp, with session description   <-- invite to alias
 75.255551  10.50.32.10 -> 10.1.39.10   SIP Status: 100 trying -- your call is important to us
 75.255867  10.50.32.10 -> 10.50.32.10  SIP/SDP Request: INVITE sip:1009@10.50.32.10:5070;LINEID=1d5a67e38809, with session description   <-- Alias resolved and invite passed to registered phone
 75.266591  10.50.32.10 -> 10.50.32.10  SIP Status: 100 Trying
 75.576971  10.50.32.10 -> 10.50.32.10  SIP Status: 180 Ringing
 75.578869  10.50.32.10 -> 10.1.39.10   SIP Status: 180 Ringing
 77.632370  10.50.32.10 -> 10.50.32.10  SIP/SDP Status: 200 OK, with session description
 77.727289  10.50.32.10 -> 10.1.39.10   SIP/SDP Status: 200 OK, with session description
 77.745453   10.1.39.10 -> 10.50.32.10  SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809   <-- ACK referencing originally dialed extension
 77.746574  10.50.32.10 -> 10.50.32.10  SIP Request: ACK sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809
 82.562176   10.1.39.10 -> 10.50.32.10  SIP Request: BYE sip:2311@10.50.32.10:5070;LINEID=1d5a67e38809   <--- BYE referencing originally dialed extension
 82.563999  10.50.32.10 -> 10.1.39.10   SIP Status: 404 SER says Not Found

I am guessing (not being an expert in SIP) that the line ID LINEID=1d5a67e38809 allows SER to route the call to the correct extension despite the difference in SIP URI?

So I guess I need a bit of code that says that matches an existing LINEID and forwards the SIP message to the end user?

Here is the current routing logic based on the textdb example but with always forward ACK


# 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","SER says Too Many Hops");
        break;
    };
    if (msg:len >=  max_len ) {
        sl_send_reply("513", "SER says Message too big");
        break;
    };

    # we record-route all messages -- to make sure that
    # subsequent messages will go through our proxy; that's
    # particularly good if upstreami and downstreami entities
    # use different transport protocol

    if (!method=="REGISTER") record_route();

    # subsequent messages withing a dialogue 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;
    };

    if (!uri==myself) {
        # mark routing logic in request
        append_hf("P-hint: outbound\r\n");
        route(1);
        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") {
            # digest authentication
            if (!www_authorize("", "subscriber")) {
                www_challenge("", "0");
                break;
            };

            save("location");
            break;
        };

        if (method=="ACK") {
           route(1);
           break;
        }

        lookup("aliases");
        if (!uri==myself) {
            append_hf("P-hint: outbound alias\r\n");
            route(1);
            break;
        };

        # native SIP destinations are handled using our USRLOC DB
        if (!lookup("location")) {
            sl_send_reply("404", "SER says Not Found");
            break;
        };
    };

    append_hf("P-hint: usrloc applied\r\n");
    route(1);
}

route[1]
{
    # send it out now; use stateful forwarding as it works reliably
    # even for UDP2TCP
    if (!t_relay()) {
        sl_reply_error();
    };
}