[asterisk-users] switching from simple_bridge technology to native_rtp issue
Sameer Rathod
sameer at hostnsoft.com
Thu Jul 10 04:28:24 CDT 2014
Hi Matt,
I also tested the directmedia=yes over 3g connection ie with a public ip
but I am getting only one way audio
am I doing anything wrong?
On Wed, Jul 9, 2014 at 6:54 PM, Sameer Rathod <sameer at hostnsoft.com> wrote:
> Hi Matt,
>
> Thank you so much for explaining me this concept
>
> One more thing when I did testing for the above in different cases ie with
> directmedia=yes and no I got the flow of packets attached with this mail
> Please have a look
>
> The flow stats that the rtp packet flows directly between end point
> So as per above details probably it is due to both of my endpoints are on
> the same network ie one side of the nat
>
> am i right?
>
>
>
>
>
>
> On Wed, Jul 9, 2014 at 6:36 PM, Matthew Jordan <mjordan at digium.com> wrote:
>
>> On Wed, Jul 9, 2014 at 4:56 AM, Sameer Rathod <sameer at hostnsoft.com>
>> wrote:
>> > Hi,
>> >
>> > with canreinvite=no and directmedia=no I and getting the message in the
>> logs
>> > for all calls
>> >
>> > "switching from simple_bridge technology to native_rtp"
>> >
>> >
>> > -- Executing [102 at mkg:1] Dial("SIP/101-00000017", "SIP/102") in new
>> stack
>> > == Using SIP RTP CoS mark 5
>> > -- Called SIP/102
>> > -- SIP/102-00000018 is ringing
>> > -- SIP/102-00000018 answered SIP/101-00000017
>> > -- Channel SIP/101-00000017 joined 'simple_bridge' basic-bridge
>> > <0ad2e3a9-e4be-4b2b-bf55-0357dafcdbab>
>> > -- Channel SIP/102-00000018 joined 'simple_bridge' basic-bridge
>> > <0ad2e3a9-e4be-4b2b-bf55-0357dafcdbab>
>> > > Bridge 0ad2e3a9-e4be-4b2b-bf55-0357dafcdbab: switching from
>> > simple_bridge technology to native_rtp
>> > > 0x7f427c068a10 -- Probation passed - setting RTP source
>> address to
>> > 111.118.250.236:49344
>> > > 0x7f427c068a10 -- Probation passed - setting RTP source
>> address to
>> > 111.118.250.236:49344
>> > > 0x7f42500168d0 -- Probation passed - setting RTP source
>> address to
>> > 111.118.250.236:26326
>> > > 0x7f42500168d0 -- Probation passed - setting RTP source
>> address to
>> > 111.118.250.236:26326
>> > -- Channel SIP/101-00000017 left 'native_rtp' basic-bridge
>> > <0ad2e3a9-e4be-4b2b-bf55-0357dafcdbab>
>> > -- Channel SIP/102-00000018 left 'native_rtp' basic-bridge
>> > <0ad2e3a9-e4be-4b2b-bf55-0357dafcdbab>
>> > == Spawn extension (mkg, 102, 1) exited non-zero on 'SIP/101-00000017'
>> >
>> >
>> >
>> > I cannot understand why asterisk state diff bridges if all works same
>> >
>> > please can anyone explain me the working bridging concept and how to
>> > configure and use bridges to route the rtp externally form asterisk.
>> >
>>
>> I think I just answered this in your other thread, but I'll repeat it
>> here.
>>
>> First, canreinvite has been deprecated as a naming convention for ...
>> a long time. It's not even documented any more. The code will accept
>> it, but all you're doing is setting the directmedia option twice:
>>
>> } else if (!strcasecmp(v->name, "directmedia") ||
>> !strcasecmp(v->name, "canreinvite")) {
>> ast_set_flag(&mask[0], SIP_REINVITE);
>> ast_clear_flag(&flags[0], SIP_REINVITE);
>>
>> The native RTP bridge in Asterisk 12 manages bridges between two RTP
>> capable channels. The bridge can either be formed remotely (in which
>> case the media flows between the endpoints) or locally, in which case
>> the media is swapped across the ports. It will attempt to perform a
>> remote bridge if possible, while falling back to a local bridge if a
>> remote bridge is not possible.
>>
>> In your particular case, you've explicitly told it to *not* do
>> directmedia. So it won't perform a remote bridge.
>>
>> Even if you set directmedia=yes (or one of its variants), you may not
>> have a successful remote bridge if one of the endpoints is behind a
>> NAT. The sip.conf sample configuration documentation is actually quite
>> good on this subject:
>>
>> ;----------------------------------- MEDIA HANDLING
>> --------------------------------
>> ; By default, Asterisk tries to re-invite media streams to an optimal
>> path. If there's
>> ; no reason for Asterisk to stay in the media path, the media will be
>> redirected.
>> ; This does not really work well in the case where Asterisk is outside
>> and the
>> ; clients are on the inside of a NAT. In that case, you want to set
>> directmedia=nonat.
>> ;
>> ;directmedia=yes ; Asterisk by default tries to redirect
>> the
>> ; RTP media stream to go directly from
>> ; the caller to the callee. Some devices
>> do not
>> ; support this (especially if one of
>> them is behind a NAT).
>> ; The default setting is YES. If you
>> have all clients
>> ; behind a NAT, or for some other
>> reason want Asterisk to
>> ; stay in the audio path, you may want
>> to turn this off.
>>
>> ; This setting also affect direct RTP
>> ; at call setup (a new feature in 1.4
>> - setting up the
>> ; call directly between the endpoints
>> instead of sending
>> ; a re-INVITE).
>>
>> ; Additionally this option does not
>> disable all reINVITE operations.
>> ; It only controls Asterisk generating
>> reINVITEs for the specific
>> ; purpose of setting up a direct media
>> path. If a reINVITE is
>> ; needed to switch a media stream to
>> inactive (when placed on
>> ; hold) or to T.38, it will still be
>> done, regardless of this
>> ; setting. Note that direct T.38 is
>> not supported.
>>
>>
>>
>>
>> Matt
>>
>> --
>> Matthew Jordan
>> Digium, Inc. | Engineering Manager
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> Check us out at: http://digium.com & http://asterisk.org
>>
>> --
>> _____________________________________________________________________
>> -- 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
>>
>
>
>
> --
> Regards
> Sameer Rathod
> 8109413462
>
>
--
Regards
Sameer Rathod
8109413462
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140710/1901148b/attachment.html>
More information about the asterisk-users
mailing list