Hi Simon Yes, the en-bloc behaviour is then clearly induced by your inbound transit carrier. Swisscom will do overlap by default after a unique routing direction is evident (1XXX0XX) whereas they have different filter sets to route value added and emergency numbers to an NPRN or not so they need to collect the first 7 digits before the routing decision is made. But if your equipment is unable to handle overlap routing table lookups and route selection, your transit provider is probably doing digit collection and either waits for a # to send you whatever is in the buffer or has an defined interdigit timeout of n seconds. Put an analyzer on your trunk and capture the SS7 MTP3 to see whether SAMs are being transmitted or you see an f at the end of the address indicating forced dialing or a complete enbloc address. If you have a DMS, it has a feature to define digit count per prefix, which speeds up the post dial delay for destinations with standardized number lengths, such as Switzerland or the US. Unfortunately, there is countries with a numbering plan having variable number sizes, the worst I know being Austria, having numbers as short as +43XXXXX given to customers and some with up to 20+ digits. It is a clear quality characteristic to have overlap dialing end to end with the incumbent carrier to send an ACM when the number is found in a local PBX. However, even some major labels are unable to handle overlap and totally cripple the quality of service giving high PDD. Only selected equipment supports overlap over SIP because of interworking issues. I even don?t know whether Asterisk supports that today. I have found a recent discussion about RFC4497: http://lists.digium.com/pipermail/asterisk-users/2011-September/266009.html Cisco does: http://www.cisco.com/en/US/docs/voice_ip_comm/pgw/9/feature/module/9.7_3_/si p_overlap.html#wp1054594 Regards, Florian (consulting Swiss OLOs as well) Von: asterisk-ss7-bounces at lists.digium.com [mailto:asterisk-ss7-bounces at lists.digium.com] Im Auftrag von Simon Handschin Gesendet: Freitag, 2. M?rz 2012 21:37 An: asterisk-ss7 at lists.digium.com Betreff: Re: [asterisk-ss7] chan_ss7 incoming callbycall call problems Hi thank you for your fast answer. Its about carrier pre selection eg i make a call from an external phone (not connected to the server) with our cpc like 1234. 12340041441234567 The Call will be routet to our server from the provider. They have enbloc enabled. Dialplan is like exten => _12340041xxxxxxxxxx (for switzerland and i know digits lenght) Its the # key because of the enbloc from our Provider? Greetings, Simon Am 02.03.2012 20:37 schrieb <florian at gruendler.net>: Define "callbycall" number. What is the callflow? Accepted where, by what equipment? Are you trying to describe something which has to do with overlap vs. enbloc dialing in a call-through scenario with digit collection on Asterisk or is this a one stage call where the call enters and leaves Asterisk in one go? By what means is this ISDN phone connected to the Asterisk machine? How does the dialplan look like? > -----Urspr?ngliche Nachricht----- > Von: asterisk-ss7-bounces at lists.digium.com [mailto:asterisk-ss7- > bounces at lists.digium.com] Im Auftrag von Simon Handschin > Gesendet: Freitag, 2. M?rz 2012 20:07 > An: asterisk-ss7 at lists.digium.com > Betreff: [asterisk-ss7] chan_ss7 incoming callbycall call problems > > Hello everyone. > > I have a problem. I have a callbycall number routet to our E1 Server. > If i Dial from my ISDN Phone to this callbycall number the call only get > acceptet if i press # key. Normal dial in and out works on our server just if > dial with call by call it did not work. > > I Use > > Sangoma A104 Card (Only 1 Port is Used) > > Asterisk 1.8.9.3 > Dahdi 2.6 > chan_ss7 2.1.0 > Wanpipe 3.5.25 > > dahdi systems.conf > > #autogenerated by /usr/sbin/wancfg_dahdi do not hand edit #autogenrated on > 2012-03-02 #Dahdi Channels Configurations #For detailed Dahdi options, view > /etc/dahdi/system.conf.bak loadzone=de defaultzone=de > > #Sangoma A104 port 1 [slot:3 bus:13 span:1] <wanpipe1> > span=1,0,0,ccs,hdb3,crc4 > bchan=1-31 > echocanceller=mg2,2-31 > #hardhdlc=1 > > wanpipe1.conf > > > #================================================ > # WANPIPE1 Configuration File > #================================================ > # > # Date: Wed Dec 6 20:29:03 UTC 2006 > # > # Note: This file was generated automatically > # by /usr/local/sbin/setup-sangoma program. > # > # If you want to edit this file, it is > # recommended that you use wancfg program > # to do so. > #================================================ > # Sangoma Technologies Inc. > #================================================ > > [devices] > wanpipe1 = WAN_AFT_TE1, Comment > > [interfaces] > w1g1 = wanpipe1, , TDM_VOICE, Comment > > [wanpipe1] > CARD_TYPE = AFT > S514CPU = A > CommPort = PRI > AUTO_PCISLOT = NO > PCISLOT = 3 > PCIBUS = 13 > FE_MEDIA = E1 > FE_LCODE = HDB3 > FE_FRAME = CRC4 > FE_LINE = 1 > TE_CLOCK = MASTER > TE_REF_CLOCK = 0 > TE_SIG_MODE = CCS > TE_HIGHIMPEDANCE = NO > TE_RX_SLEVEL = 430 > HW_RJ45_PORT_MAP = DEFAULT > LBO = 120OH > FE_TXTRISTATE = NO > MTU = 1500 > UDPPORT = 9000 > TTL = 255 > IGNORE_FRONT_END = NO > TDMV_SPAN = 1 > TDMV_DCHAN = 0 > TE_AIS_MAINTENANCE = NO #NO: defualt YES: Start port in AIS > Blue Alarm and keep line down > #wanpipemon -i w1g1 -c Ttx_ais_off to disable > AIS maintenance mode > #wanpipemon -i w1g1 -c > Ttx_ais_on to enable AIS maintenance mode > TDMV_HW_DTMF = NO # YES: receive dtmf events from hardware > TDMV_HW_FAX_DETECT = NO # YES: receive fax 1100hz events from > hardware > HWEC_OPERATION_MODE = OCT_NORMAL # OCT_NORMAL: echo cancelation > enabled with nlp (default) > # OCT_SPEECH: > improves software tone detection by disabling NLP (echo possible) > # > OCT_NO_ECHO:disables echo cancelation but allows VQE/tone functions. > HWEC_DTMF_REMOVAL = NO # NO: default YES: remove dtmf out of > incoming media (must have hwdtmf enabled) > HWEC_NOISE_REDUCTION = NO # NO: default YES: reduces noise on > the line - could break fax > HWEC_ACUSTIC_ECHO = NO # NO: default YES: enables acustic > echo cancelation > HWEC_NLP_DISABLE = NO # NO: default YES: guarantees > software tone detection (possible echo) > HWEC_TX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio > level to be maintained (-20 default) > HWEC_RX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio > level to be maintained (-20 default) > HWEC_TX_GAIN = 0 # 0: disable -24-24: db values to be > applied to tx signal > HWEC_RX_GAIN = 0 # 0: disable -24-24: db values to be > applied to tx signal > > [w1g1] > ACTIVE_CH = ALL > TDMV_HWEC = NO > MTU = 8 > > > ss7.conf > > [linkset-siuc] > enabled => yes > enable_st => no > use_connect => no > hunting_policy => even_mru > context => ss7 > language => de > t35 => 4000,st > subservice => auto > variant => ITU > > > [link-l1] > linkset => siuc > channels => 2-31 > schannel => 1 > firstcic => 1 > enabled => yes > sltm => no > sls=0 > echocancel => no > echocan_train => 350 > echocan_taps => 128 > > [host-SS7-1] > if-1 => 10.1.40.71 > enabled => yes > opc => 1601 > dpc => siuc:300 > links => l1:1 ;span 1 of dahdi/system.conf > ;globaltitle => 0x00, 0x03, 0x01, 7773 > ssn => 7 > > > Anyone got an idea about this? > > Greetings > > Simon > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-ss7 mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-ss7 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-ss7 mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-ss7 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20120303/716a3ddc/attachment.htm>
|