|Summary:||ASTERISK-02245: [patch] h323-sip-mgcp native bridging|
|Date Opened:||2004-08-20 08:42:26||Date Closed:||2011-06-07 14:04:43|
|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 ******
* sip with linphone and asterisk as EP only
* mgcp with swissvoice IP10S
* h323 with ohphone, tiptel
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
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:
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()
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.