Summary:	ASTERISK-02245: [patch] h323-sip-mgcp native bridging
Reporter:	kiel (kiel)	Labels:
Date Opened:	2004-08-20 08:42:26	Date Closed:	2011-06-07 14:04:43
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) native_rtp_bridging.diff
Description:	This patch enhances the feature submitted in bug ASTERISK-2172204 (it means that it contains the former patch) A full description is reported at ASTERISK-2172204 (that have been almost totally ignored, like me on the irc channel). Here I only added sip support and adapted for the last CVS-HEAD I hope someone will be interested in performing large load tests (I haven't got enough material for) ****** ADDITIONAL INFORMATION ****** patch infos: * CVS-HEAD-08/20/04-12:59:56 * sip with linphone and asterisk as EP only * mgcp with swissvoice IP10S * h323 with ohphone, tiptel no gatekeeper no fastStart, no h245Tunneling used with Dial application.
Comments:	By: twisted (twisted) 2004-08-20 09:07:28 Is this the bug you would like to keep open then?  One of the two will be closed, please decide wich one you would like to keep open. By: kiel (kiel) 2004-08-20 10:30:56 yup you can close ASTERISK-2172204 and ASTERISK-2082113 both patches are included here. By: twisted (twisted) 2004-08-20 13:28:27 Done. Thanks ;) By: jerjer (jerjer) 2004-08-20 14:40:29 Wouldn't placing the call on hold cause a drop out in audio? By: kiel (kiel) 2004-08-20 17:08:22 It will. The most significant loose of rtp packets is in h323 because of the several "steps" needed to perform renegociation. 2 main steps are particulary criticals 1/ between call establishement (answering dial) and native_bridging Throughout the tests I've done, evrything was processed very quickly so that usually no more than 10 RTP packets were lost before entering native_bridging. This could be avoided by directly shunt the called peer on the calling at call establishement (not done yet). I prefered considering a more general situation where both peers are already involved in an ast context, so that they already have established h245 negociations. 2/ between call holding and call retreiving that's what you're talking about I think. In fact, it's done in two steps with MGCP or SIP whereas it's performed in 4 in h323 (worst case of two h323 Ep bridging). While on hold, no rtp is sent nor received by the calling peer (channels are down) expecting that asterisk carries out called peer holding. From the tests I've done, it runs quite well and quickly so that for a context such as the following: => Answer() => Dial(H323) the time elapsed beetwen the end of the ringing bell (for gnomemeeting as soon as the H225 procedure ends up) and the start of the conference is very short, so that it is not noticed by the user. Now I don't know how it supports important loads. There is another problem too, and I added some remarks on that point in the source code. What happens when the native_bridging procedure crashes with the called peer ? (for exemple the calling EP is put on hold successfuly but the other prepare() procedure fails) For the moment, nothing is done to try to rescue the call between the two endpoints, and to grab the media back on asterisk. It shouldn't be that tricky to implement but would involve more lateness. By: twisted (twisted) 2004-10-01 11:55:28 Closing due to over a month with no activity.  This can be re-opened or a new bug created to handle this in the future.