The WaitIfBufferedPacketPresent=1 setting typically doesn't have much impact unless you add the SerialAutoAnswer=1 parameter along with it. With this, you'll probably want to bring MsToWaitForCallInfo back down a bit again.
Here's a sequence of events notorious for causing this type of failure...
1. CallA hits Port1 and serial PacketA arrives
2. CallA is abandoned before Port1 answers (often internal callers that are forward to voicemail hang up the call as soon as the phone display shows they've been forwarded)
3. With analog lines, Unity has no easy way to know CallA was aborted. We have to wait for a long break in the ring cadence. Thus Unity still thinks CallA and PacketA are valid
4. CallB arrives on Port1 just around the time Unity attempts to answer CallA
5. CallB gets greeting that was intended for CallA
So, here's how the above parameters help mitigate that problem...
- Somewhere around step 2, Unity takes Port1 offhook due to SerialAutoAnswer
- Unity waits for MsToWaitForCallInfo to ensure PacketA is the last packet sent for CallA and not some stale packet left over from a previous call.
- Now, Unity must clear Port1 (go onhook) before CallB can arrive. Thus PacketA is cleared from the cache and the game starts again.
The real catch here is, as you note, the PBX keeps hammer calls onto the first few ports. What we really need is a guard timer on the PBX that'll prevent consecutive calls on the same port. SerialAutoAnswer, in a way, creates this guard timer. Unfortunately, it still can not be 100% but it should provide significant improvement.
Regards,
Eric
