Re: [asterisk-users] chan_capi audio weirdness
Hi Armin, On 18/02/2012 19:28, Arik Raffael Funke wrote: in NT mode, the B-channel is not activated automatically. You have to signal the TE side that early-B3 data is available. Then the TE side can activate the B-channel. If the NT-side is chan_capi, use exten = _X.,n,capicommand(progress) I tried what you suggested - but without any luck. To make sure I did not misunderstand you, I now have: exten = _X.,1,capicommand(progress) exten = _X.,n,Dial(CAPI/capi_intern/12345/b) To help identification of the problem, my console prints the following after capicommand(progress): [Feb 19 10:45:08] WARNING[3483]: chan_capi.c:4972 show_capi_conf_error: ISDN_INTERN#02: conf_error 0x2001 PLCI=0x103 Command=SELECT_B_PROTOCOL_CONF,0x8495 ISDN_INTERN#02: CAPI INFO 0x2001: Message not supported in current state Regards, Arik -- _ -- 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
Re: [asterisk-users] Should you ever use nat=no?
On 02/16/2012 12:30 PM, Kevin P. Fleming wrote: On 02/11/2012 06:59 PM, Bruce B wrote: If your server is open to the internet and in SIP general section you have nat=no and in peers you have nat=yes or vice versa then it's possible to enumerate your extension. Because Asterisk responds with different messages if the extension exists or not based on that difference in the nat setting then it's possible to tell if an extension 100 exists or not. Over the past few years, Digium has come to realization to respond to all unauthenticated calls the same way in order to thwart any attack attempts or guesses on the extension but it's still not perfect yet as these improvements are done at a really slow pace. Regardless, they are being made and there truely is a security risk. really slow pace? Please point out any one of these issues that took an unnecessarily long time to resolve once it was identified and brought to the development team's attention. I always use nat=yes. I don't even know why nat=no exists as there is nothing that can't be done with nat=yes. Plus nat=yes will take care of some of the surprise one-way audio scenarios as well so why use nat=no at all?! I vote to totally get rid of the nat setting all together and hard code it and set it to yes but again there are others who may not agree. As was already pointed out in the discussions that lead up to the 'nat' default being changed, there are SIP endpoints out there that do not work properly with 'nat=yes' (or 'nat=force_rport'). They behave improperly when Asterisk adds an 'rport' parameter to the top-level Via header in its responses. Setting 'nat=no' is the only way to keep this from happening. So in my case, these 40 internal sip devices (primarily aastra), which are not nat'd with respect to asterisk, should all be nat=yes unless they are unable to deal with the rport parameter? And if they are unable, setting nat=yes would immediately break them? If not, what are the symptoms of being unable to behave properly with the rport parameter? sean -- _ -- 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
Re: [asterisk-users] Should you ever use nat=no?
On 02/19/2012 09:42 AM, sean darcy wrote: On 02/16/2012 12:30 PM, Kevin P. Fleming wrote: On 02/11/2012 06:59 PM, Bruce B wrote: If your server is open to the internet and in SIP general section you have nat=no and in peers you have nat=yes or vice versa then it's possible to enumerate your extension. Because Asterisk responds with different messages if the extension exists or not based on that difference in the nat setting then it's possible to tell if an extension 100 exists or not. Over the past few years, Digium has come to realization to respond to all unauthenticated calls the same way in order to thwart any attack attempts or guesses on the extension but it's still not perfect yet as these improvements are done at a really slow pace. Regardless, they are being made and there truely is a security risk. really slow pace? Please point out any one of these issues that took an unnecessarily long time to resolve once it was identified and brought to the development team's attention. I always use nat=yes. I don't even know why nat=no exists as there is nothing that can't be done with nat=yes. Plus nat=yes will take care of some of the surprise one-way audio scenarios as well so why use nat=no at all?! I vote to totally get rid of the nat setting all together and hard code it and set it to yes but again there are others who may not agree. As was already pointed out in the discussions that lead up to the 'nat' default being changed, there are SIP endpoints out there that do not work properly with 'nat=yes' (or 'nat=force_rport'). They behave improperly when Asterisk adds an 'rport' parameter to the top-level Via header in its responses. Setting 'nat=no' is the only way to keep this from happening. So in my case, these 40 internal sip devices (primarily aastra), which are not nat'd with respect to asterisk, should all be nat=yes unless they are unable to deal with the rport parameter? And if they are unable, setting nat=yes would immediately break them? If not, what are the symptoms of being unable to behave properly with the rport parameter? You are correct on both points. It is doubtful that your endpoints will misbehave with 'force_rport' enabled (or its equivalent in older versions), but if they do, it will be immediate (and not subtle). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.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
