RFP Response Document to All Relevant Technical Inquires

Transcription

1 Questions 1 Does project include also proposal for the central ENUM database? If yes, where are NO requirements for it? 2 Is it a Fixed NP database? NO 3 REQ299 and REQ424 say that Core Router and Firewall need to be redundant, but in table page 37 (RFP) quantities for them are one, but for Core Switch is two. Please explain this issue. Answers It should support redundancy, for future expansion. 4 How many equipment placement sites will be in this project? 1 (one) 5 Do we have to include Georedundancy in offer? NO 6 REQ29. What kind of protocols are you planning to use over DS3? SS7\ISUP 7 Please specify, how many SS7 Signaling Links are required? Total 30 SS7 Signaling Links 8 Please specify, how many SIP-trunks are required? No limitation 9 Please specify, how many SIP-I/T links are required? No limitation 10 How many TDM lines expected? What is the Erlang Value for these trunks? Please specify 11 Can you please confirm average call hold time is 90 sec for traffic calculations? Yes DS0 lines, ACD=90 second, ASR=50% 12 Can you please specify the number of each type physical interfaces? Upon demand 13 How many STM1 interface required? How many DS3 interface required? How many T1/E1 channelized interfaces required? STM1- upon demand DS3 upon demand 420 E1 14 How many concurrent SIP sessions expected? Minimum SIP sessions, Minimum 250 transcoding sessions 15 Codec Ratios Considering the list of codecs what are the ratio of usage of those codecs, can you please specify? a. AMR-NB b. EVRC0 c. EVRC-A d. EVRC-B e. G.711 a-law and mu-law f. G.722 g. G (AMR-WB) h. G i. G.726 j. G.728 k. G.729a/b l. G.729e m. GSM FR n. ilbc No specifications, mentioned codecs shall be supported.

2 16 REQ#29 The MGW should support the DS3, No Can you please confirm having active DS3 links in the live network 17 REQ#45 The solution shall be able to generate Call Detail Records (CDRs). The CDR shall contains at least the following key fields: Calling party Called party (as received) Destination party (as sent out, e.g. after ENUM query) Incoming route Outgoing route Seizure time (date and hour) Answer time (if applicable date and hour) Media type (for audio, video and events) Release time (date and hour) Releasing party Release reason (a SIP error code and/or ISUP release cause) There is a mistake in typing, it is not ADR, it is CDR. Please describe your solution. Please indicate which functional element in your architecture will be responsible to create the ADRs. Can you please give more details about ADRs? 18 REQ#73 The offered session border controller solution shall support Registration Throttling (i.e. outbound registration rate limiting): Protect core network multimedia infrastructure entities from receiving large amount of keep alive registrations by throttling keep alive registrations received from SIP devices and locally respond by sending 200 OK. This requirement defines an access SBC behavior, SIP Register method is not used in peering (class 4) architecture. Please explain your view. 19 REQ#79 The offered session border controller solution shall support access control lists - IP based, DID based, subnet based. 20 REQ#80 The offered session border controller solution shall protect against theft of service through strict protocol and payload inspection and policing. 21 REQ#97 The offered session border controller solution shall support ANI and DNIS manipulation. This is functional requirement. Most of SBC support both interconnect and access SBC functionality in the same box/software. For security purpose. For security purpose This is basic functionality of telecom switching equipment 22 REQ#99 For future business plans

3 The offered session border controller solution shall support Multi-vendor interop - IP PBX's, softswitches, IP Phones, IADs, SBC, GWs. Question: Solution offered by BIDDER provides class 4 services. This covers trunking capabilities. To server softphones and IADs class 5 services need to be introduced. BIDDER suggests removing of class 5 devices from the list. 23 REQ #113 The offered session border controller solution shall provide detailed analysis on business, service, and network performance - cost of network, revenue of network, profitability/ loss analysis. (serving enterprise customers). Having any interoperability with the listed devices will be an advantage for the bidder This is required functionality. Can you please provide more clarifications on this feature, use cases and/or example. 24 REQ#118 The offered session border controller solution shall provide consolidated view of multiple CDRs for the same session that spans multiple SBC for terminating a session. 25 REQ#119 The offered session border controller solution shall support routes based on: a. Digit Based routing based on Called Party (DNIS) or Calling Party (ANI) digits - NPA, NPA NXX, NPA NXXX based b. Outgoing Trunk Group (OTG) / Destination Trunk Group (DTG) c. Domain based routing d. Originating Line Information (OLI) e. Local Routing Number (LRN) f. Call Identification Code (CIC) g. IP address of incoming /outgoing trunks h. Incoming and outgoing cost factors (Margin / best / profit based routing) - LCR, and profitability based i. Capacity-Based Routing j. Percentage-based routing k. Time of Day based Routing l. Day of Week Routing m. Priority-Based Routing Question: can you please explain the "Capacity based routing" and "Priority based routing". 26 REQ#207 The offered monitoring solution shall support real-time call statistics at node and carrier level with graph and matrix views Question: Can you please explain what is meant by carrier level? 27 REQ#153 The offered session border controller solution shall support DIAMETER (Rx interface with PCRF). For future expansion Priority based routing is General Capacity based routing is according to operator demand Carrier means operator or provider, interconnect For the future requirements or radius integration.

4 Question: The expected behavior is a part of access SBC (class 5 ). Not applicable in desired solution. Please share your vision. 28 REQ#239 The centralized routing engine shall support role based access control and full audit trail Question: What is role based access control? 29 REQ#244 The centralized routing engine shall support zone routing Question: what is zone routing? 30 REQ#245 The centralized routing engine shall support US domestic and jurisdictional routing by LATA and state: Question: What is meant by state? In computer systems security, role-based access control (RBAC) is an approach to restricting system access to authorized users. Trunks can be grouped under different zones and if required, trunks will be available only within assigned zones or zones can have priority over other zones. Routing is overwritten by these rules where necessary. LATA stands for Local Transport and Access Area. A LATA is a contiguous geographic area. LATA is your local calling area. Therefore intralata means the same thing - your local calling area (inside a particular LATA). A LATA can cover an entire state so all the state will be considered intralata, and all calls within that state will be considered local calls (usually for small states). Most states have several LATAs. InterLATA refers to calls between 2 LATAs. These can be 2 LATAs located in the same state, or 2 LATAs located in different states. Therefore long distance calls. Interstate calls are calls between two states. These calls can also be considered interlata because they are calls between 2 LATAs. Intrastate calls are calls within the same state. This term is rather confusing because calls within the same state can be

5 31 REQ#253: The centralized routing engine shall support for different egress routing types based on combinations of SIP Trunk Group, DNIS Tech prefix, and IP Addresses of Provider Gateways Question: What is meant by DNIS Tech prefix and IP Addresses of Provider Gateways? 32 REQ#257 The routing logic engine shall support rule based automated route policy management Question: Requirement not understood. Can you please explain business driver and use case (example) 33 REQ#260: The routing logic engine shall support preventing cherry picking: Question: what is cherry picking? Can you explain the business driver and use case? either interlata or intralata. This is about how to differentiate carriers. Let s tag carrier A with 3333 and carrier B with 4444 prefix. Or instead only IP address of gateways can be used. If it s a shared IP, a combination of IP and tech prefix can be used in order to identify carriers. Additional routing logic should be able to be added to providers selection in a short term. For example, checking local number portability data table before applying route logic. Or applying translation rules based on trunk before applying the route logic. If in supplier cost sheet, let s assume the buy rates are like follows: $ $ $ $ $ $ $ $ $ $ 34 REQ#270 The routing logic engine shall support fetching of automated updates Question: Not understood. Can you explain the business driver and use case? 35 REQ#275 The billing server shall support integrated configurable supplier rate importing with routing Question: Can you clarify who is the supplier and the business driver and the use case? If customer offer to 905 is 0.25$, this supplier will not be used and discarded. Because 9053 is not offered and the cost of 9053 calls will be 0.3$ which will cause 0.05 negative margin. This is just the application s auto update functionality, not related with routing. Offer to customers are managed with a fixed format. But suppliers offers are all different formats, there s no standard. System comes with a wizard to normalize different pattern of

6 36 REQ#277 The billing server shall support general ledger both for prepaid and postpaid interconnect carries with all in and out data Question: since the ISS (IGW Node) does not have the end customer information, what is the aim to differentiate the prepaid and postpaid calls? This information will not be available on most of the cases. Or are these the prepaid postpaid customers mentioned here as the carriers getting service? If so, can you clarify for the prepaid use case? 37 REQ#278 The billing server shall support SoA (statement of account) Question: We understand as, the account mentioned here is the carrier customers accounts, can you confirm? cost sheets. This is not class 5 level. Payment models are related with class 4 arbitrage models. Existing models are prepaid, postpaid, or postpaid with credit limit which is very similar to prepaid. If operator will only allow to a carrier to populate calls with a prepayment only, this is prepaid. It can be done through a cash transfer or setting a credit. After calls are accumulating, outstanding balance will run out and should be replenished. Yes 38 REQ#312 The shall offer equipment with minimum 3 years support packets. Question:Can you please clarify what is meant by 3 years support packets 39 REQ#1 SIM Box detection service should include a limitless number of countermeasures to avoid that fraudsters detect the test calls. Following countermeasures are included and will be customized and optimized in accordance with the specific situation in the country: Question: In the normal flow of the SIM Box usage, the calls are not expected to go over the ISS lines, instead go over the IP connections as VoIP calls until they are handed to the local operator s network via SIM Box. Hence, it doesn t seem to be practical to try to detect the SIM Box fraud on ISS network. Can you clarify the cases that you would like to prevent? 40 REQ# Core Router Question-1: Card Redundancy is not mentioned in RFP for Core Router? Alcatel-Lucent concern is there should be card redundancy as well in case of any failure as the whole IMS IP Router structure will be single point of failure. 41 REQ# Core Router Question-2: there aren t any GE, 10GE, E1, E3, STM-1, STM-4, STM-16 port quantity requirements for Core Router in RFP. The type of cards and the minimum quantity of port requirements are not defined. What are the minimum GE, 10GE, E1, E3, STM-1, STM-4, STM-16 port numbers? It means 3 year of support period mentioned To ensure that all the calls will be processed through the ISS. Core Router must have min. 6 Gig Ethernet ports. These ports are in 1+1 redundant state. The offered Core Router shall have minimum 6 Gigabit Ethernet ports with 2 SFP Modules (one LX and one SX) and Base-T Ethernet ports.

7 42 Core Switch: REQ 336# The offered Core Switches shall support port security and IEEE 802.1x user Authentication standard. Question: Are you going to connect users on core devices, do you need this function for the E2E Solution? 43 REQ 368# The offered Data Center ToR Switches shall support 1/10 Gigabit Ethernet ports SFP/SFP+ (Supported transceiver and cables include Twinax SFP-H10GB-CU1M, SFPH10GB- CU3M, SFP-H10GB-CU5M, SFP-H10GB-ACU7M, and SFP-H10GB-ACU10M, include SFP+ SFP-10G-SR, SFP-10G-LR, and include SFP GLC-T, GLC-SX-MM, GLC- LH-SM, SFP-GE-T, SFP-GE-S, SFP-GE-L). IEEE 802.1x standart is needed for future needs. The offered Core Switches shall support port security and IEEE 802.1x user Authentication standard. The offered DC ToR Switches shall support 1/10 Gigabit Ethernet ports and mentioned above SFP Modules. The offered each Data Center ToR Switch must have minimum 24 x 1000BaseT ports or modules. Question: Which sfp type are you going to use?.these sfp s should be tested some of them is not in our portfolio. 44 REQ# Core Switch According to RFQ *10 Gbit ports needed.according to RFQ *1Gbit ports requested. Question: Can you please clarify your requirements is it 10 gbitports also support 1Gbit or 40*10 Gbit, 24* 1gbit at the same chassis? The offered each Data Center ToR Switch must have minimum 2 x 10 Gb SR modules. Each core switch must have minimum 40 x 1/10 Gbps Base- X ports. 24 port of them must have 1000Base-T GBIC modules.