[Serusers] Unexpected disconnect - lost SIP packets?

[Greger V. Teigre]

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 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/75ab9044/attachment.htm>