[Serusers] Unexpected disconnect - lost SIP packets?

[Jeremy A]

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 at fesa.sto. It gets reformed to
1001 at 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 at 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 at 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 at 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 at 10.50.32.10:5070;LINEID=1d5a67e38809
 82.562176   10.1.39.10 -> 10.50.32.10  SIP Request: BYE
sip:2311 at 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();
    };
}

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20071129/65308b61/attachment.htm>