[asterisk-users] Setting up RTP to flow between endpoints directlybypassingAsterisk

[Klaus Darilion]

Hi Jeff!

Looks like the term "native bridging" is a bit overloaded.

Some text from channel.h:
         -# When the call is answered, Asterisk bridges the media streams
            so the caller on the first channel can speak with the callee
            on the second, outbound channel
         -# In some cases where we have the same technology on both
            channels and compatible codecs, a native bridge is used.
            In a native bridge, the channel driver handles forwarding
            of incoming audio to the outbound stream internally, without
            sending audio frames through the PBX.
         -# In SIP, theres an "external native bridge" where Asterisk
            redirects the endpoint, so audio flows directly between the
            caller's phone and the callee's phone. Signalling stays in
            Asterisk in order to be able to provide a proper CDR record
            for the call.


See also
http://lists.digium.com/pipermail/asterisk-dev/2010-March/043052.html


klaus

Am 17.03.2010 23:34, schrieb Jeff Brower:
> Klaus-
>
>> Am 16.03.2010 01:42, schrieb Jeff Brower:
>>> Vikram-
>>>
>>>> http://www.voip-info.org/wiki/view/Asterisk+Letting+SIP+clients+connect+directly
>>>>
>>>> The link above indicates that it is possible to setup RTP streams to
>>>> directly flow between endpoints and completely bypass Asterisk. I would
>>>> like to know if this configuration would work when,
>>>>
>>>> a) both endpoints are behind NAT, and/or
>>>> b) both endpoints don't support same codecs
>>>>
>>>> with media flowing through a SIP+rtpproxy server that can do
>>>> transcoding ?
>>>
>>> This would be 'native bridging' mode as I've seen it described a few places on the web, correct?  If Asterisk is "out
>>> of the RTP loop", then what can it still do?  Only billing?  It would not detect DTMF, no RTP record or announcement
>>> playout, etc.
>>
>> No, this this is not native bridging.
>>
>> Asterisk supports 3 methods of media handling:
>> 1. bridging: media (audio, video) is received on one channel, handled
>> over to Asterisk's core, forwarded to the bridged channel, and sent out
>> again.
>>
>> 2. native-bridging: if both bridged channels use the same technology
>> then media can be bridged directly in the channel driver, no need to
>> feed the media into Asterisk's core. For example SIP-to-SIP calls or
>> DAHDI-to-DAHDI calls.
>
> This is not what I understood initially from the Digium / voip-info.org web pages.
> For example in the SIP-to-SIP case, are you saying that still the motherboard NIC
> would be used and the Linux kernel would "touch" every packet, but Asterisk software
> would not?  My understanding was that RTP would flow direct between the NICs on the
> devices.
>
>> 3. bypass: here, the media flow bypasses Asterisk directly. AFAIK this
>> works only with SIP as channel technology. This comes in 2 flavors:
>>
>>    3a) During call setup the media will be forwarded via Asterisk. Once
>> the call is set-up, Asterisk will send reINVITEs to both clients using
>> the clients original SDP contact information. For this you must set
>> canreinvite=yes (1.4) or directmedia=yes (1.6) in sip.conf. Of course
>> Asterisk will initiate the direct media only if the media is not needed
>> in Asterisk, e.g. if you monitor a call, the media will always be routed
>> via Asterisk.
>
> Ok this is what I was expecting.  I thought that canreinvite=yes was equivalent to
> native bridging, but evidently there is a distinction here that I need to study.
>
>>    3b) Media will bypass Asterisk from the beginning. Therefore you have
>> to set directrtpsetup=yes. This is still experimental and causes weird
>> reINVITEs (e.g. after call setup to lock down on a certain codec or
>> after call termination to redirect media to Asterisk before hanging up).
>>
>> Both bypass modes Note only work if either there are no NATs at all, or
>> the clients are behind the same NAT and do not use STUN.
>
> Ok.  Thanks for this info.  I was not aware of directrtpsetup.
>
> -Jeff