Vakee,
What you see is the normal behavior for such high delay.
1800 ms is even worth than a setelite connection delay.
Here is a snapshot of the SRND:
If QoS is not deployed, packet drops and excessive delay and jitter can occur, leading to impairments of
the telephony services. When media packets are subjected to drops, delay, and jitter, the user-perceivable
effects include clicking sound, harsh-sounding voice, extended periods of silence, and echo.
When signaling packets are subjected to the same conditions, user-perceivable impairments include
unresponsiveness to user input (such as delay to dial tone), continued ringing upon answer, and double
dialing of digits due to the user's belief that the first attempt was not effective (thus requiring hang-up
and redial). More extreme cases can include endpoint re-initialization, call termination, and the spurious
activation of SRST functionality at branch offices (leading to interruption of gateway calls).
This is basically what your are encountering.
The recommendation is to have one way delay <= 150 ms
Delay in IP Voice Networks
Recommendation G.114 of the International Telecommunication Union (ITU) states that the one-way
delay in a voice network should be less than or equal to 150 milliseconds. It is important to keep this in
mind when implementing low-speed WAN links within a network. Topologies, technologies, and
physical distance should be considered for WAN links so that one-way delay is kept at or below this
150-millisecond recommendation. Implementing a VoIP network where the one-way delay exceeds
150 milliseconds introduces issues not only with the quality of the voice call but also with call setup and
media cut-through times because several call signaling messages need to be exchanged between each
device and the call processing application in order to establish the call.
I don't think there is any ways of tweaking parameters with such high delay.
You are facing a design issue.
Better put a local CME at each remote site and connect them with a SIP trunk to the central CUCM cluster.
Pierre.
