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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> wrote: >> >>> On Wed, Jul 9, 2014 at 4:56 AM, Sameer Rathod <[email protected]> >>> 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@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
-- _____________________________________________________________________ -- 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
