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

[Arkadi Shishlov]

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?

[Venefax]

I add myself to the idea. Asterisk needs just that.
F.Alves

-----Original Message-----
From: asterisk-dev-***@lists.digium.com
[mailto:asterisk-dev-***@lists.digium.com] On Behalf Of Arkadi Shishlov
Sent: Thursday, May 21, 2009 7:45 AM
To: asterisk-***@lists.digium.com
Subject: [asterisk-dev] Media traffic handling by external host (different
IP)

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?

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev

[Jared Smith]

Post by Arkadi Shishlov
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.

[Kevin P. Fleming]

Post by Jared Smith
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).

[Arkadi Shishlov]

On Thu, 21 May 2009 08:35:18 -0500

Post by Kevin P. Fleming
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.

[Tzafrir Cohen]

I figure I'm missing quite a few things here. But whatever :-)

Post by Arkadi Shishlov
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
- 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.

Could you be more specific at where exactly this does not work?

Sanity check: Why doesn't your card talk SIP with Asterisk through the
extra interface it has?

[Arkadi Shishlov]

On Thu, 21 May 2009 16:02:55 +0300

Post by Tzafrir Cohen
IIUC, chan_sip can work that way. Naturally anything that relies on

No sure it can. How?

Post by Tzafrir Cohen
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 understand that.

Post by Tzafrir Cohen
Could you be more specific at where exactly this does not work?

How can I sanely force chan_sip (and pbx core!) to skip media processing and just perform session control?

Post by Tzafrir Cohen
Sanity check: Why doesn't your card talk SIP with Asterisk through
the extra interface it has?

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.

[Kevin P. Fleming]

Post by Arkadi Shishlov
How can I sanely force chan_sip (and pbx core!) to skip media processing and just perform session control?

You cannot. Asterisk is a B2BUA, it will always be involved in media
processing during call setup.