[Serusers] One failure_route problem remaining

[Greger V. Teigre]

Corey S. McFadden wrote:
> Greger,
>
> Thanks again for the response. We're working with the vendor now on
> the GW problem.  They think their equipment might not be responding
> properly to the OK from Asterisk.  (It doesn't seem to be a very
> talkative piece of equipment.)

:-) At least you have a responsive vendor. Most other vendors I have heard 
referred just say "no, we don't have a problem."

> In any case, a few of the other questions linger:
>
>>> - I notice a lot of "Warning: sl_send_reply: I won't send a reply
>>>   for ACK!!" but don't know if this is significant or not.  From
>>>   what I've read it sounds like ACKs are getting an sl_reply rather
>>>   than being t_relayed but I didn't really modify anything related
>>> ... ?
>>
>> Yes, this error tells you that ACKs end in an sl_reply, which they
>> shouldn't. You need to identify the type of ACKs (probably related
>> to your GW, as a guess), so you can make sure the ACKs are handled
>> correctly.
>
> I added:
>        if (uri==myself) {
>
>                if (method=="ACK") {
>                        route(1);
>                        break;
> } else if ...
>
> to the main route's method check and it didn't seem to help.  If this
> is an acceptable method I'll have to continue to research to see how
> an sl_reply could be happening.
>

Try to add debug statements and do ngrep (or tcpdump and sip_scenario) so 
that you can identify the "bad" ACK in the context of a dialog.

g-)