I was playing around with the ctd.sh script and my SER setup w/ ATA-186 clients. I got it to work by adding a simple "ACK" to the ctd script after the INVITE response and before the REFER. The documentation page indicates that this ACK happens in the ctd example, but running a tcpdump/ngrep on the SER machine showed that it never did.
The only problem I have is that when I send an ack through the fifo, it looks like SER is waiting for a response, so it takes a good 20 seconds or so before it gives up and moves onto the REFER.
Is there an easy way to convince SER to not wait for a response to an ACK through the FIFO? I thought there was a fifo command to do this but couldn't find one...
Also for anybody who cares, the REFER method works with the ATA-186 firmware 2.16 and higher, but I also created a modified version of the ctd script that completed the calls using the BYE/Also method that works on pre-2.16 ATAs.
- Mike
At 10:00 PM 11/5/2003, Mike wrote:
I was playing around with the ctd.sh script and my SER setup w/ ATA-186 clients. I got it to work by adding a simple "ACK" to the ctd script after the INVITE response and before the REFER. The documentation page indicates that this ACK happens in the ctd example, but running a tcpdump/ngrep on the SER machine showed that it never did.
interesting -- for me, it does generate the ACK. If it does not, something is wrong.
there is certainly one shortcoming I'm aware of which is the ACK is generated like ACKs for negative replies (ingoring dialog rules, i.e., sending to the same destination as INVITE and ignoring route set). That should not however prevent the ACK from being seen.
Can you send me the ngreps?
[...]
Also for anybody who cares, the REFER method works with the ATA-186 firmware 2.16 and higher, but I also created a modified version of the ctd script that completed the calls using the BYE/Also method that works on pre-2.16 ATAs.
that's nice, please send it over to me.
Thanks,
-jiri