[asterisk-users] switching from simple_bridge technology to native_rtp issue
Sameer Rathod
sameer at hostnsoft.com
Thu Jul 10 04:30:04 CDT 2014
sorry I forgot to add the conf
sip.conf
[101]
type=friend
username=101
secret=101
host=dynamic
context=mkg
;nat=force_rport,comedia
;dtmfmode=rfc2833
;canreinvite=no
directmedia=yes
;directrtpsetup=yes
;avpf=yes
;encryption=yes
;disallow=all
;allow=ulaw
;icesupport=yes
[102]
type=friend
username=102
secret=101
host=dynamic
context=mkg
;nat=force_rport,comedia
;dtmfmode=rfc2833
;canreinvite=no
directmedia=yes
;directrtpsetup=yes
;avpf=yes
;encryption=yes
;disallow=all
;allow=ulaw
;icesupport=yes
On Thu, Jul 10, 2014 at 2:58 PM, Sameer Rathod <sameer at hostnsoft.com> wrote:
> 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
>
>
--
Regards
Sameer Rathod
8109413462
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140710/179cf568/attachment.html>
More information about the asterisk-users
mailing list