Re: [Serusers] Unexpected disconnect - lost SIP packets?

Greger Viken Teigre wrote: 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(a)fesa.sto. It gets reformed to 1001(a)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(); }; }