[asterisk-dev] Media traffic handling by external host (different IP)

[Arkadi Shishlov]

On Thu, 21 May 2009 08:35:18 -0500
"Kevin P. Fleming" <kpfleming at digium.com> wrote:
> It is what he's looking for; it allows for creation of RTP stack
> implementations that provide what RTP-using channel drivers (like
> chan_sip) require without the media actually flowing through the host
> running Asterisk. As Tzafrir already mentioned, making use of this
> functionality is a bit complex as Asterisk is not just a media gateway
> but also needs to have access to the media stream during call setup
> (and possibly at other times).

Could you please elaborate on "media stream during call setup"?
As I understand, access to media is needed when Asterisk itself want to play/record the channel:
- DTMF via ast_playtones()
- IVR
- conferencing
- spy
In case of pure media gateway, ie. simple call between ISDN and SIP, using appropriate IP address and port in SDP will do the job, right?

Can you describe the case why plug-able RTP framework was created?

Correct me if I'm wrong, but the Asterisk core always expects to read/write the media from/into channel [except that you can queue the reads via ast_queue_frame()]. Then RTP-using channel could use whatever RTP implementation is required.
I briefly reviewed trunk rtp_engine.c and it looks of no help to me. It has read/write handlers like a channel, so it confirms that the usage is
pbx -> channel write() -> rtp implementation write()

What is required in general case, is something like a dynamic REINVITE, where channel can internally indicate to Asterisk core that it could handle media bridging natively. Likewise Asterisk could tell to the driver, that media endpoint is changing because it wants the data and channel driver should switch to read/write.

This is kinda never ending game, because conferencing and spying introduces new requirements, and so on.

Looks like for small configurations RTP offload is not critical. For large deployments the schema with external media gateway that communicates with Asterisk via SIP for PBX tasks is more appropriate.