Hi!
While the ability to set an alternate source for RTP media is being discussed I want to ask about possibility to implement support for the following scenario:
- I'm developing a channel driver - chan_nms http://chan-nms.hosting.lv/ for NMS card that has Ethernet ports and autonomous TCP/IP stack on-board.
- Currently media traffic is passed via Asterisk.
- I would be great to offload media processing - both sending and receiving from the host and push the traffic via on-board ethernet.
- Signaling is still performed by Asterisk.
As I understand, this does not fit well into Asterisk architecture, but it would be great to get it working for SIP.
Any ideas?

Hi!
While the ability to set an alternate source for RTP media is being
discussed I want to ask about possibility to implement support for the
following scenario:
- I'm developing a channel driver - chan_nms http://chan-nms.hosting.lv/ for
NMS card that has Ethernet ports and autonomous TCP/IP stack on-board.
- Currently media traffic is passed via Asterisk.
- I would be great to offload media processing - both sending and receiving
from the host and push the traffic via on-board ethernet.
- Signaling is still performed by Asterisk.
As I understand, this does not fit well into Asterisk architecture, but it
would be great to get it working for SIP.
Any ideas?

As I understand, this does not fit well into Asterisk architecture, but it would be great to get it working for SIP.

I'm not sure if this is exactly what you're looking for, but I think one
of the Asterisk developers recently rewrote some of the RTP
infrastructure to be able to support different plug-in RTP handlers. If
I recall correctly, this is only available in the trunk of the Asterisk
SVN repository at this time.

Hi!
While the ability to set an alternate source for RTP media is being
discussed I want to ask about possibility to implement support for
the following scenario:

- I'm developing a channel driver - chan_nms
http://chan-nms.hosting.lv/ for NMS card that has Ethernet ports
and autonomous TCP/IP stack on-board.
- Currently media traffic is passed via Asterisk.
- I would be great to offload media processing - both sending and
receiving from the host and push the traffic via on-board ethernet.
- Signaling is still performed by Asterisk.

As I understand, this does not fit well into Asterisk architecture,
but it would be great to get it working for SIP.

IIUC, chan_sip can work that way. Naturally anything that relies on
listening to the media (or even to signalling in the rtp stream) cannot
work. But you can't have it both ways, I guess.

I'm not sure if this is exactly what you're looking for, but I think one
of the Asterisk developers recently rewrote some of the RTP
infrastructure to be able to support different plug-in RTP handlers. If
I recall correctly, this is only available in the trunk of the Asterisk
SVN repository at this time.

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).

The card itself cannot. RTP is only thing this card is capable of.
I can write an external minimal SIP server attached to the card that will run on the same host (or a cluster), then REINVITE-ing will accomplish the task. Except that there will be no way to control the call via Asterisk any more.

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.