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 > -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users