9 Sep
2005
9 Sep
'05
7:19 a.m.
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 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-)
- 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.