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

[Jeff Brower]

Klaus-

> 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

Yes seems so.  Many layers of subtlety :-)

-Jeff

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