Summary:	ASTERISK-06458: reinvite - audio delay
Reporter:	vortex_0_o (vortex_0_o)	Labels:
Date Opened:	2006-03-02 14:16:25.000-0600	Date Closed:	2006-03-29 19:19:33.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sip.txt
Description:	audio delay of up to 1 second (normally less)  is found when asterisk steps out of the media path. This is noticable for users - often they miss the start of the call. canreinvite=yes only alaw is allowed tested with both polycom 500  and cisco 7940 phones. attached is polycom to polycom (1014 calling 1013)
Comments:	By: Timo Goetze (germansupport) 2006-03-05 08:02:32.000-0600 I have the problem with moh. after putting a call on hold and taking it back, there is a delay of around 1 sec. after ever other put on old the delay grows by some amount of time... i use only sip phones. canreinvite=no everywhere. By: Timo Goetze (germansupport) 2006-03-05 08:17:57.000-0600 one more hint: the delay happens only in one direction. By: Olle Johansson (oej) 2006-03-06 06:53:09.000-0600 If you have canreinvite=no everywhere - there are no re-invites. But in the bug report you claim that re-invites are giving you problem... By: vortex_0_o (vortex_0_o) 2006-03-06 08:42:22.000-0600 yes germansupport seems to be offtopic I only get audio delay when reinvite=yes and is taking place. By: Paul Cadach (pcadach) 2006-03-06 11:42:02.000-0600 I think this is not a bug - re-invites (any sort of, SIP's or H.323's) are implemented as total close of audio path between endpoint and switch (Asterisk) then open new audio path between two endpoints (or endpoint and gateway, no difference). This process is average slow so provides about 0.5-1 sec of delay in audio. My Utstarcom F-1000 SIP handset don't produces RTP for about 0,5 sec after it has acknowledged re-INVITE and tells to Asterisk its new RTP information. But re-invites off-loads Asterisk from RTP forwaring, reduces network "bottleneck" and allows (a little) to stay established connections online when Asterisk fails/restarts. By: Olle Johansson (oej) 2006-03-06 12:02:35.000-0600 Well, in theory, nothing should change until we get a final reply on the re-invite. We should be ready on both the old IP as well as the new while waiting for reply so we don't loose sound. That's how it works in SIP. I am unclear if Asterisk can handle that and still listen for RTP on the old ports while the re-invite transaction is alive. If the other side denies the re-invite, we should switch back which we don't do.... By: vortex_0_o (vortex_0_o) 2006-03-06 12:46:14.000-0600 So are we saying that a delay is inevitable as the media path switches to the endpoints? Or that the switch over should be seemless? (apologies in advance) By: Paul Cadach (pcadach) 2006-03-06 12:47:25.000-0600 It's just a theory. In practice (and in comparsion with H.323 which I played about a week for providing native bridging support) endpoint just closes previously opened RTP stream and creates new one. Also, you shouldn't send any RTP data from old address after re-invite because some endpoints could remember an address where first RTP packet was received and don't accept packets from other addresses. Closing/opening RTP stream/socket could provide a change of endpoint's listening port. If both endpoints changes its ports then it will cause "re-invite loop". By: vortex_0_o (vortex_0_o) 2006-03-06 12:56:25.000-0600 So ideally a setting to force rtp between the endpoints initially would be the only way to avoid the delay? (something like a dial option when you know in advance it is going to work) By: Paul Cadach (pcadach) 2006-03-06 13:00:02.000-0600 Yep. But sometimes it's not possible (especially for early media, etc.). By: vortex_0_o (vortex_0_o) 2006-03-06 13:11:45.000-0600 excuse my lack of sip knowledge but assume it isn't possible to do the functional equivalent of a reinvite before the call goes through 2xx By: Olle Johansson (oej) 2006-03-29 19:19:20.000-0600 Not a bug report any more. Discussions are better handled in the mailing list. THanks.