The IPO is sending a "roundtrip delay request" to the ATA. The ATA answers the delay, but the IPO doesn't seem to "accept" the answer. After 3 faulty attempts, the IPO disconnects the call...
I haven't found any adjustments in either the IPO or the ATA that has to do with this issue..
We have reported the issue to Avaya, together with the generally hopeless H323 functionality, but they doesn't seem to care.
In the product-description it's mentioned that the H323 support standard call-transfer and call-hold, which i haven't got to work on any VoIP-adapter.
Avaya's answer: This is an error in the product-description! Transfer/Hold is only supported on Avaya IP-sets and SCN.
We find it to be a problem that hold/transfer on H323 can make the IPO malfunction! Avaya doesn't seem to care although..
I have also reported to Avaya and they really investigate.
I disagree the malfunction of H.323 functionality because my IPaq with WiFi and a softphone ( HJPhone ) does work ok, including the hold function and transfers ( need a thirth party H.323 license ).
I will report the findings of Avaya on this forum later.
By the way, right now i connect to a VPN line on the IP Offie and get this problem. If i register as a extension then it's working ok, the disadvantage is that i can only use one port and not two and have to buy licenses.
This is disappointing because the ATA has two ports so i am determent to get both ports working, even if i have to work months on this with Avaya.
I have both, actually, i have all licenses.
This is not a licensing issue, there is something fundamentally wrong with thirth party H.323 connections wich has to solved.
Oh, sorry.
If configured via a VPN line then a license is not needed but this scenario give a connection of 65 seconds so you have to speak quickly enough.
If configured as a H.323 terminal then you can only use one alog channel and the IP endpoint license is needed. This did work ok without problems including transfers.
The problem lays in the Cisco ATA it seems.
The IP Office sends during a conversation keep alive packets in a sequence and expects a answer from the other device to send a answer with the corresponding sequence number.
Example : The IP Office sends :
MultimediaSystemControlMessage = request =
roundTripDelayRequest = sequenceNumber = 7
The Cisco should answer :
MultimediaSystemControlMessage = response =
roundTripDelayResponse = sequenceNumber = 7
But it answers with :
MultimediaSystemControlMessage = response =
roundTripDelayResponse = sequenceNumber = 0
Therefore the IP Office presumes to lost contact and after 10 requests IP Office will clear the channel for other users.
Avaya suggest to go to Cisco in order to let them fix it as the IP Office fully confirms the H.323 standards on this.
I have no entrance to the Cisco TAC for support, so it ends here for me.
Has anyone had any luck with this recently. I still get the disconnect, even when programmed as a station. This thread seems to indicate, when programmed as a station (user), it doesn't drop the call. That hasn't been my experience.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.