asterisk users - Jul 2014 - switching from simple_bridge technology to native_rtp issue

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.

-- 
Regards
Sameer Rathod
8109413462
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20140709/49530370/attachment.html>

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