[Serusers] RE: [Serdev] call drop

[Helge Waastad]

Hello,
I don't know if anyone has written anythine else on this matter,
but I agree that the ACK's usually are misrouted.

In my case, I add a 0 (zero) before a forward the call to the cisco
gateway.
When SER receives an ACK to sip:0<number>, it is not caught by the
"PSTN" route, but is caught by the "if(!lookup())" script, and hence (in
my case) forwarded to handling_unavailiable_users (voicemail).

Right now, as an interim solution, I've modified the !lookup to exclude
ACK's, but I do not think this is the right way of doing it.

My debug was like this:

0(23172)  method:  <ACK>
 0(23172)  uri:     <sip:048095461 at yyy.yyy.yyy.yyy:5060>
 0(23172)  version: <SIP/2.0>
 0(23172) parse_headers: flags=1
 0(23172) Found param type 235, <rport> = <n/a>; state=17
 0(23172) end of header reached, state=5
 0(23172) parse_headers: Via found, flags=1
 0(23172) parse_headers: this is the first via
 0(23172) After parse_msg...
 0(23172) preparing to run routing scripts...
 0(23172) DEBUG : sl_filter_ACK: to late to be a local ACK!
 0(23172) DEBUG : is_maxfwd_present: searching for max_forwards header
 0(23172) parse_headers: flags=128
 0(23172) get_hdr_field: cseq <CSeq>: <6909> <ACK>
 0(23172) DEBUG: add_param: tag=61F29B28-E79
 0(23172) end of header reached, state=29
 0(23172) DEBUG: get_hdr_field: <To> [42]; uri=[sip:48095461 at xxxx.xx]
 0(23172) DEBUG: to body [<sip:48095461 at xxxx.xx>]
 0(23172) DEBUG: get_hdr_body : content_length=0
 0(23172) found end of header
 0(23172) DEBUG: is_maxfwd_present: max_forwards header not found!
 0(23172) parse_headers: flags=64
 0(23172) Someone's trying to register for Private IP, rewriting....
 0(23172) parse_headers: flags=64
 0(23172) parse_headers: flags=33554432
 0(23172) DEBUG: add_param: tag=547CFF73
 0(23172) end of header reached, state=29
 0(23172) parse_headers: flags=256
 0(23172) check_self - checking if host==us: 10==12 && 
[yyy.yyyy.yyy.yyy] == [xxx.xxx.xxx.xxx]
 0(23172) check_self - checking if port 5060 matches port 5060
 0(23172) check_self - checking if host==us: 12==12 && 
[xxx.xxx.xxx.xxx] == [xxx.xxx.xxx.xxx]
 0(23172) check_self - checking if port 5060 matches port 5060
 0(23172) parse_headers: flags=256
 0(23172) found end of header
 0(23172) fnr(): No next Route HF found
 0(23172) ras(): No next URI found
 0(23172) lookup(): '048095461' Not found in usrloc
 0(23172) query="select grp from grp where username='048095461' AND
grp='voicemail'"
 0(23172) is_user_in(): User is not in group 'voicemail'
 0(23172) lookup(): '048095461' Not found in usrloc
 0(23172) Enter voicemail route......
 0(23172) parse_headers: flags=44
 0(23172) Warning: sl_send_reply: I won't send a reply for ACK!!


br hw

At 12:43 PM 4/8/2004, Raymond Chen wrote:
>Then what should I do to take care of the problem? 

I'm not sure even what the problem is. If a call is dropped after one
minute that's hardly related to mismatched reply. Similar behaviour
often happens when an ACK is misrouted. Just watch SIP traffic to see
what is going on.

-jiri

> I 've use the simple example and test every added step now.
>
>Ray
>
>-----Original Message-----
>From: Jiri Kuthan [mailto:jiri <at> iptel.org] 
>Sent: Thursday, April 08, 2004 6:18 PM
>To: Raymond Chen; serusers <at> iptel.org
>Cc: serdev <at> iptel.org
>Subject: Re: [Serdev] call drop
>
>At 03:17 AM 4/8/2004, Raymond Chen wrote:
>>Dear all,
>> 
>>We¡¯ve setup a call scenario AS5300-¨¤SER¨¤as5300  but all calls drop around 1
minute after connection, 
>
>SER does not keep transactions in memory for ever. If you wish them
>to be kept longer, try longer TM timers. Nevertheless, the reply
>in question should be delivered statelessly even if the transaction
>context is already expired.
>
>-jiri 
>
>
>
>_______________________________________________
>Serdev mailing list
>Serdev <at> iptel.org
>http://lists.iptel.org/mailman/listinfo/serdev

--
Jiri Kuthan            http://iptel.org/~jiri/