[Serusers] sl_send_reply: I won't send a reply for ACK!! - Problem Identified

[Mark Aiken]

Not that this will help much, but, I've seen a problem like this when 
loose_route() fails to identify the message as being to ser (that is 
myself). For example if the GW is at the same IP address but a different 
port and the port is not included in an alias.

Mark

On 9/9/05, Corey S. McFadden <csm-lists at csma.biz> wrote:
> 
> 
> Guys,
> 
> I was able to figure out why I was getting occasional sl_send_reply errors
> with some ACK messages. I don't know if this is something that needs to
> be corrected at a deeper level, but I'll give you the rundown:
> 
> 1. UA Makes a call to a bad number
> 2. Bad number is actually valid so it gets routed to the GW
> 3. GW responds 404
> 4. ACK loop occurs.
> 
> When the ACK loop happens, SIP captures reveal the following (watch the
> Max-Forwards):
> 
> #1
> ..
> Max-Forwards: 9
> Record-Route: <sip:ser;ftag=0014a934057d001145ed0fa2-6f6f2e8e;lr=on>
> Via: SIP/2.0/UDP ser;branch=0
> Via: SIP/2.0/UDP 192.168.249.83:5060 <http://192.168.249.83:5060>
> ;received=otherip;branch=z9hG4bK140d833e
> ..
> #2
> ..
> Record-Route: <sip:ser;ftag=0014a934057d001145ed0fa2-6f6f2e8e;lr=on>
> Max-Forwards: 8
> Record-Route: <sip:ser;ftag=0014a934057d001145ed0fa2-6f6f2e8e;lr=on>
> Via: SIP/2.0/UDP ser;branch=0
> Via: SIP/2.0/UDP ser;branch=0
> Via: SIP/2.0/UDP
> 192.168.249.83:5060 <http://192.168.249.83:5060>
> ;received=otherip;branch=z9hG4bK140d833e
> ..
> 
> 
> Etc. etc. until Max Forwards counts down to 0, at which point:
> 
> if (!mf_process_maxfwd_header("10")) {
> sl_send_reply("483", "Too Many Hops");
> break;
> };
> 
> And naturally:
> sl_send_reply: I won't send a reply for ACK!!
> 
> 
> So, I've obviously been able to avoid this by changing to:
> 
> if (!mf_process_maxfwd_header("10")) {
> if (method!="ACK") {
> sl_send_reply("483", "Too Many Hops");
> };
> break;
> };
> 
> 
> Now, the greater question: is the ACK loop being generated by a defective
> message. If so, is it anything to worry about? And in either case is
> putting the method check in there a valid solution?
> 
> Can anyone advise?
> 
> Thanks,
> -Corey
> 
> 
> *********************************************
> This message has been scanned for viruses and
> dangerous content, and is believed to be clean.
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050909/fd86485d/attachment.htm>