I seem to have fixed the problem with a 'hack' that looks for packets directed to port 5070 and sends them to route(1)

I think that is probably the correct solution and is RFC compliant? However it puzzles me that the test uri==myself doesn't take into account the port number.

NB my regex skills are low so the check for port 5070 is certainly sub-optimal, however it works :-)

Thanks for your help

New routing code:

    if (uri==myself) {

        if (method=="REGISTER") {
            # digest authentication
            if (!www_authorize("", "subscriber")) {
                www_challenge("", "0");
                break;
            };

            save("location");
            break;
        };

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

	# send on any uri that goes to port 5070 - it's not us

        if (search(":5070")) {
	   route(1);
	   break;
	}

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


Greger V. Teigre wrote:
The BYE should have a Route header, which is used for routing. If it does not have a Route header, the UA originating the BYE must be fixed. Of course, you can hack the BYE by doing the same kind of alias rewriting as the INVITE, but it is not RFC-compliant.
g-)

Jeremy A wrote:
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