at à 11:45 PM on le February 14, 2014

Transcription

1 RETURN RESPONSES TO: RETOURNER LES RÉPONSES À: Josée St-Onge Contracting Authority Autorité contractante Shared Services Canada Services partagés Canada 180 Kent Street, 13th floor 180, rue Kent, 13 ième étage Ottawa, Ontario K1P 0B6 INVITATION TO QUALIFY INVITATION À QUALIFIER Title Sujet Integrated Communications & Support Services (ICSS) - National Services intégrés nationale de communications et de soutien (SICS) Solicitation No. N de l invitation Date 2B0KB /A 7 février 2014 Client Reference No. N référence du Amd No. No de la modif. client 008 File No. N de dossier 2B0KB Time Zone Solicitation Closes L invitation prend fin Fuseau horaire at à 11:45 PM on le February 14, 2014 F.O.B. - F.A.B. Plant-Usine: Destination: Other-Autre: Address Inquiries to : - Adresser toutes questions à: Josée St-Onge Telephone No. N de téléphone : Delivery required - Livraison exigée See Herein Destination of Goods, Services, and Construction: Destination des biens, services et construction : Eastern Standard Time (EST) / Heure Normale de l'est (HNE) Buyer Id Id de l acheteur C96 FAX No. N de FAX Not applicable Delivered Offered Livraison proposée See Herein Comments - Commentaires Vendor/firm Name and address Raison sociale et adresse du fournisseur/de l entrepreneur THIS DOCUMENT CONTAINS A SECURITY REQUIREMENT CE DOCUMENT CONTIENT DES EXIGENCES RELATIVES À LA SÉCURITÉ Facsimile No. N de télécopieur Telephone No. N de téléphone Name and title of person authorized to sign on behalf of Vendor/firm (type or print)- Nom et titre de la personne autorisée à signer au nom du fournisseur/de l entrepreneur (taper ou écrire en caractères d imprimerie) Issuing Office Bureau de distribution SSC SPC Procurement and Vendors Relationships Achats et relations avec les fournisseurs Voice Networks Section Section des réseaux de voix 180 Kent Street, 13th floor 180, rue Kent, 13 ième étage Ottawa, Ontario K1P 0B6 Signature Date Page 1 of 8

2 INVITATION À QUALIFIER (IAQ) MODIFICATION 008 Cette modification à l invitation à se qualifier est soulevée pour: 1. Fournir des réponses aux questions des répondants. QUESTIONS ET RÉPONSES Question No. 211 Services partagés Canada (SPC) peut-il fournir une méthodologie de classification qui permettrait au système de téléphonie IP d identifier les appels de niveau de priorité inférieur, c.-à-d. est-il suffisant d identifier simplement que tous les appels sont moins prioritaires lorsque l identification de la ligne appelante (ILA) indique 911? Réponse No.211 La méthodologie de classification sera confirmée durant la période allouée a la conception et la configuration des systèmes de téléphone IP suivant l attribution du contrat. Les soumissionnaires sont priés de faire référence à la réponse No.117 pour de plus amples renseignements. Question No. 212 Veuillez fournir des précisions : Les messages vocaux doivent-ils être chiffrés lorsqu ils sont stockés sur un disque dur, et la seule méthode de chiffrement indiquée à l élément 610 est-elle la seule permise? Réponse No.212 Les soumissionnaires sont priés de faire référence à la réponse No.55 pour de plus amples renseignements. Question No. 213 Cette question concerne la modification n o 004, page 2 de 26, qui stipule ce qui suit : «En accord avec l article 2.4 du document de l invitation à se qualifier, l échéance pour soumettre des demandes et des renseignements était le 28 janvier Le Canada ne fait aucun engagement pour fournir des réponses aux questions soumises après le 28 janvier 2014.» Nous souhaitons souligner respectueusement que cet extrait N EST PAS conforme aux termes de l article 2.4 qui précise que «Les demandes de renseignements et les commentaires concernant l invitation à se qualifier et la version provisoire de la demande de soumissions, y compris les suggestions visant à améliorer les spécifications, doivent être présentés par écrit à l autorité contractante au moins 10 jours civils avant la date de clôture de l invitation à se qualifier.» De nombreuses questions demeurent sans réponse. Afin que SPC puisse tirer profit de son nouveau processus de solutions d approvisionnement collaboratif (solutions qui permettent la formulation de commentaires pendant cette phase de la part de l industrie), il est essentiel que les fournisseurs disposent d assez de temps pour formuler des commentaires au sujet des exigences et obtenir des précisions à leur sujet. Pourriez-vous confirmer que SPC répondra aux questions conformément aux termes énoncés à l origine à l article 2.4? Page 2 de 8

3 Réponse No.213 Veuillez vous référer à la réponse No. 210 de l invitation à se qualifier, modification 007. Question No. 214 En ce qui concerne l annexe A1, section 9.8.2, élément 308.c, qui indique «l interconnexion complète SIP, H.323, SIP-I, SIP-T», SIP-I et SIP-T font référence à deux approches très similaires de l interconnexion des réseaux ISUP et SIP. Le protocole ISDN User Part ou ISUP fait partie du système de signalisation par canal sémaphore n o 7, et nous comprenons que SPC n utilise pas un réseau interne SS7. SIP-I et SIP-T sont orientés vers le fournisseur de services plutôt que vers l entreprise. Par conséquent, le Canada accepterait-il de supprimer «SIP-I et SIP-T» de l élément 308.c? Réponse No.214 Ligne (308) c) l'interconnexion complète SIP, H.323, SIP-I, SIP-T de l annexe A1 Énoncé des travaux sera supprimé. À l annexe A1- Énoncé des travaux, section Exigences fonctionnelles des contrôleurs de session en périphérie de l'entreprise, ligne (308) c) est modifiée comme suit : SUPPRIMÉ c) l'interconnexion complète SIP, H.323, SIP-I, SIP-T; Question No. 215 En ce qui concerne l annexe A1, section 9.8.3, élément 310.a, point 3, qui indique «RFC 3398 : Application ISUP-SIP», le protocole ISDN User Part ou ISUP fait partie du système de signalisation par canal sémaphore n o 7 et est utilisé pour établir des connexions filaires entre les échanges. L application ISUP et ISUP-SIP est une fonction de fournisseur de services destinée à un environnement de télécommunications et non d entreprise. Nous comprenons que SPC n utilise pas un réseau interne SS7. Par conséquent, le Canada accepterait-il de supprimer le point 3 «RFC 3398 : Application ISUP-SIP» de l élément 310.a, puisque cette fonction n est pas pertinente dans un contexte d entreprise? Réponse No.215 Ligne (310) a) point 3 de l annexe A1, section : RFC 3398: Application ISUP-SIP sera supprimé. À l annexe A1- Énoncé des travaux, section Exigences techniques, ligne (310) a) point 3 est modifié comme suit : SUPPRIMÉ 3. RFC 3398: Application ISUP-SIP; Question No. 216 En ce qui concerne l annexe A1, section 9.8.3, élément 310.a, point 5, qui indique «RFC 3578 : Chevauchement», la RFC 3578 décrit une méthode permettant au signal du protocole de réseau numérique à intégration de services (ISUP) de chevaucher le signal du protocole Session Initiation Protocol (SIP). Le protocole ISDN User Part ou ISUP fait partie du système de signalisation par canal sémaphore n o 7 et est utilisé pour établir des connexions filaires entre les échanges. Le protocole ISUP et la RFC 3578 : Chevauchement représentent une fonction de fournisseur de services destinée à un environnement de télécommunications et non d entreprise. Nous comprenons que SPC n utilise pas un réseau interne SS7 et qu il n utilisera jamais cette fonction à l interne puisqu il s agit d une fonction utilisée exclusivement par les fournisseurs de services. Par conséquent, le Canada accepterait-il de supprimer le Page 3 de 8

4 point 5 «RFC 3578 : Chevauchement», de l élément 310.a, puisque cette fonction n est pas pertinente dans un contexte d entreprise? Réponse No.216 Ligne (310) a) point 5 de l annexe A1, section, section 9.8.3: RFC 3578: Chevauchement sera supprimé. À l annexe A1- Énoncé des travaux, section Exigences techniques, ligne (310) a) point 5 est modifié comme suit : SUPPRIMÉ 5. RFC 3578: Chevauchement Question No. 217 Annexe A1, section 9.8.3, paragraphe 310.a, point 7 : «RFC 3581 : Une extension du protocole SIP affecté au routage de réponse symétrique». Il semble que cette exigence fasse partie des nombreuses exigences des sections E-SBC axées sur le fournisseur de services qui ne se retrouvent pas au bon endroit, qui ne sont pas, ou très peu, pertinentes pour l entreprise ou pour lesquelles les cas d usage sont inexistants ou rares dans l entreprise. En règle générale, cette norme RFC s applique aux utilisateurs à distance, souvent à la maison, qui utilisent des appareils de traduction d adresses de réseau (NAT) faisant appel au protocole de datagramme d utilisateur (UDP) lorsqu ils tentent de se connecter de nouveau au réseau de l entreprise sur l Internet. Ces problèmes de NAT, d UDP et de SIP peuvent être résolus à l aide des contrôleurs de session en périphérie du fournisseur de services, lesquels sont hébergés sur le réseau SIP interne de la porteuse, et il ne s agit pas d une fonction requise au sein de l entreprise. De plus, l industrie abandonne la norme RFC 3581 pour adopter une nouvelle technologie plus fonctionnelle, soit l Interactive Connectivity Establishment (ICE) de l Internet Engineering Task Force (IETF), qui offre, entre autres, la fonction de traversée NAT avec l UDP. Puisque la norme RFC 3581 est applicable à l environnement SP ET que l industrie utilise de plus en plus l ICE, le Canada pourrait-il supprimer le point 7 du paragraphe 310.a : «RFC 3581 : Une extension du protocole SIP affecté au routage de réponse symétrique», puisque cette fonction n est pas appliquée de façon uniforme au sein de SPC ou qu elle n est pas pertinente? Réponse No.217 Ligne (310) a) de l annexe A1, section 9.8.3, point 7: RFC 3581: Une extension du protocole SIP affecté au routage de réponse symétrique sera modifié comme suit : 7. RFC 3581: Une extension du protocole SIP affecté au routage de réponse symétrique, ou optionnellement, les RFC suivants: A) RFC 5245: Organisme de connectivité interactive (ICE); et B) RFC 5389: Utilitaires de session de traversée pour la traduction d'adresse réseau (STUN); et C) RFC 5766: Traversée utilisant des relais autour de la traduction d adresse réseau (TURN): Extensions de relais aux utilitaires de session de traversée pour la traduction d'adresse réseau (STUN) À l annexe A1 Énoncé des travaux, section Exigences techniques, ligne (310) a) point 7 est modifié comme suit : SUPPRIMÉ 7. RFC 3581: Une extension du protocole SIP affecté au routage de réponse symétrique; INSÉRÉ 7. RFC 3581: Une extension du protocole SIP affecté au routage de réponse symétrique, ou optionnellement, les RFC suivants: A) RFC 5245: Organisme de connectivité interactive (ICE); et Page 4 de 8

5 B) RFC 5389: Utilitaires de session de traversée pour la traduction d'adresse réseau (STUN); et C) RFC 5766: Traversée utilisant des relais autour de la traduction d adresse réseau (TURN): Extensions de relais aux utilitaires de session de traversée pour la traduction d'adresse réseau (STUN) Question No. 218 Annexe A1, section 9.8.3, paragraphe 310 a), point 10 : «RFC 3892 : Mécanisme Referred-By». Il y a très peu de cas d usage de cette norme RFC. Un usage pertinent est lié à certaines applications particulières des centres d appel ou de contacts. Pratiquement aucune application de centre d appel ou de contacts n utilise cette norme RFC, y compris celles de Cisco, d Avaya, de Genesys et d autres fabricants, et un cas d usage de cette norme RFC au sein de SPC est donc très improbable. De plus, SPC établira bientôt une norme RFP pour les centres de contacts, ce qui nécessiterait probablement une nouvelle application standard pour les centres de contacts de l ensemble de SPC, laquelle n a pas encore été déterminée. On suggère que SPC révise le cas d usage correspondant à cette exigence. Il semble que cette exigence de l E-SBC n est pas nécessaire et qu elle ne se trouve pas au bon endroit. Puisque la norme RFC 3892 ne semble pas pertinente dans ce contexte, le Canada pourrait-il supprimer le point 10 du paragraphe 310.a : «RFC 3892 : Mécanisme Referred-By»? Réponse No.218 Ligne (310) a) de l annexe A1, section 9.8.3, point 10 «RFC 3892: Mécanisme Referred-By» sera modifié comme suit: 10. RFC 3892: Mécanisme Referred-By (le cas échéant); À l annexe A1 Énoncé des travaux, section Exigences techniques, (310) a), point 10 est modifié comme suit : SUPPRIMÉ 10. RFC 3892: Mécanisme Referred-By; INSÉRÉ 10. RFC 3892: Mécanisme Referred-By (le cas échéant); Question No. 219 Annexe A1, section 9.8.3, paragraphe 311.a : «Prise en charge du transfert de codes vocaux : G711a, G711µ, G723, G723.1, G729, G726, codecs cellulaires pour GSM, UMTS et LTE, y compris le codec audio capable de s adapter à des catégories multiples AMR, codec Internet Low Bitrate (ilbc)». L UMTS est une technologie de téléphonie mobile de troisième génération (3G) pour les réseaux qui utilisent le GSM. Le LTE est une norme de communication sans fil et de transfert de données à haute vitesse pour les téléphones cellulaires et les terminaux de données qui utilisent le GSM/EDGE et l UMTS/HSPA. L UMTS et le LTE sont des technologies SP et de porteuse qui utilisent des passerelles cellulaires où le SP et la porteuse effectuent la conversion de code; il ne s agit ABSOLUMENT PAS d une fonction de l entreprise et SPC n a pas non plus à effectuer la conversion de code à l interne. À l instar des autres exigences et normes RFC qui ont été désignées comme relevant de l environnement SP et qui ont été supprimées pendant le processus de question, le Canada pourrait-il supprimer les exigences relatives à l UMTS et au LTE du point 10 du paragraphe 311.a : «Prise en charge du transfert de codes vocaux : G711a, G711µ, G723, G723.1, G729, G726, codecs cellulaires pour GSM, UMTS et LTE, y compris le codec audio capable de s adapter à catégories multiples AMR, codec Internet Low Bitrate (ilbc)», puisqu ils ne sont pas au bon endroit et qu ils ne sont pas pertinents? Réponse No. 219 Ligne (311) a) de l annexe A1, section sera modifié comme suit : Page 5 de 8

6 a) Prise en charge du transfert de codes vocaux : G711a, G711µ, G723, G723.1, G729, G726, codec Internet Low Bitrate (ilbc); et À l annexe A1 Énoncé des travaux, section Exigences techniques, (311) a) est modifié comme suit : SUPPRIMÉ a) Prise en charge du transfert de codes vocaux : G711a, G711µ, G723, G723.1, G729, G726, codecs cellulaires pour GSM, UMTS et LTE, y compris le codec audio capable de s'adapter à catégories multiples AMR, RTC/Lync, codec Internet Low Bitrate (ilbc); et INSÉRÉ a) Prise en charge du transfert de codes vocaux : G711a, G711µ, G723, G723.1, G729, G726, codec Internet Low Bitrate (ilbc); et Les soumissionnaires devraient faire référence aux réponses No.100 et No.103 pour de plus amples renseignements. Question No. 220 En réponse à la question 78, dans la modification 004, SPC a supprimé l exigence relative au soutien IPv6 pour les téléphones IP. Le gouvernement du Canada s est engagé à déployer une infrastructure IPv6 et des points d extrémité au cours des deux prochaines années. La réponse de SPC à la question 78, laquelle a donné lieu à la suppression de l IPv6 pour les téléphones IP, crée des risques importants ainsi que des problèmes d harmonisation pour le gouvernement du Canada, c.-à-d. risque que les téléphones IP fournis par les SICS nationaux nuisent au déploiement de l IPv6 (ainsi que l engagement du Canada en cette matière), voire l empêchent, pour toute la période de six ans visée par l entente d approvisionnement des SICS nationaux. Plutôt que de supprimer complètement l exigence relative à l IPv6 pour les téléphones IP, SPC pourrait peut-être adopter une stratégie d atténuation des risques techniques et financiers auxquels s expose le gouvernement du Canada. Pour ce faire, SPC pourrait accepter les soumissionnaires qui proposent des téléphones IPv4 en précisant que tous les téléphones ne fonctionnant que sous IPv4 doivent être remplacés par des téléphones IPv6 dans un délai de 90 jours suivant une demande de mise à niveau de SPC. Grâce à cette approche, le gouvernement du Canada n aurait pas à assumer les coûts des nouveaux téléphones IPv6 lorsque les réseaux seront mis à niveau. Une mise à niveau matérielle ou logicielle téléchargée à distance sur chaque téléphone IP ou par le soumissionnaire qui remplacera les téléphones IPv4 par des téléphones IPv6 pourrait être envisagée, et ce sans frais pour SPC. Puisque SPC a adopté une approche similaire avec le Service d accès à distance protégé du Gouvernement du Canada pour résoudre un problème causé par de multiples systèmes d exploitation, le Canada a déjà établi un précédent en la matière. Réponse No. 220 La réponse No. 222 remplace le contenu de la réponse no. 77. Les colonnes A et B de l appendice F à l annexe A1 - Fonctions de l appareil d utilisateur, ligne 52 est modifiée comme suit : 52 Doit supporter le protocole IP version 4 et version 6 (le cas échéant)) À l annexe A1 Énoncé des travaux, section 28 - l appendice F à l annexe A1 - Fonctions de l appareil d utilisateur, ligne 52 est modifiée comme suit : SUPPRIMÉ 52 Doit supporter le protocole IP version 4 Page 6 de 8

7 INSÉRÉ 52 Doit supporter le protocole IP version 4 et version 6 (le cas échéant)) Question No. 221 Voici l exigence du Canada dans l invitation 2B0KB /B, annexe A1 Énoncé des travaux, point (184) : (184) «L entrepreneur doit fournir une suite logicielle sous licence dans laquelle les logiciels du composant des systèmes de téléphonie IP proviennent d'un seul référentiel d'application logicielle. Par exemple, le traitement des appels peut s effectuer sur un ensemble varié de matériels, mais le logiciel qui en est responsable doit provenir d'un seul référentiel d'application logicielle.» Selon notre interprétation de cette clause, chaque type de système, selon la définition qui en est faite à l annexe B, Tableau des prix pour les systèmes de téléphonie IP de classes 1 à 5, doit utiliser le même logiciel, et ce, quelle que soit sa plateforme matérielle. Cela signifie-t-il que les systèmes de téléphonie IP de toutes les classes doivent être déployés avec la même version de logiciel pour uniformiser l expérience de gestion, réduire le nombre d appels de soutien et les coûts connexes, assurer l interopérabilité entre tous les téléphones IP de SPC et établir une expérience utilisateur commune pour toutes les classes de systèmes de téléphonie IP? Réponse No. 221 Le terme «d'un seul référentiel d'application logicielle» signifie que tous logiciels offerts par l entrepreneur furent testé favorablement pour assurer leurs interopérabilités fut vérifiées avec tous les autres composantes des systèmes de téléphonie IP, furent vérifier en laboratoire, ont favorablement complétés tous les tests d acceptation et seront supporter par l entrepreneur pour la durée du contrat subséquent. The terme ne doit pas être interprété comme ni étant applicable à un manufacturier d équipement d origine ni que le logiciel doit parvenir d un fournisseur spécifique. Question No. 222 En ce qui concerne les lignes 287 et 307 de l'annexe A1 et en particulier la nécessité d'un soutien AS- SIP, la question n 54 de l'offre de SICS précédente pour la RCN demandé ce qui suit : Sections (AS- SIP) et 23.1 (EAL- 1) demande des validations de sécurité qui ont historiquement seulement été requis par le Canada pour les implémentations sécurisés tel que le MDN. Il est de la compréhension du soumissionnaire que très peu de fournisseurs peuvent répondre à ces exigences, ce qui semble superflu pour la majorité des sites du Canada. Si le Canada prévoit que ces certifications comme une norme de référence pour ses futures implémentations de VoIP, il semble déraisonnable de ne pas fournir des fournisseurs de préavis et suffisamment de temps pour devenir certifié- en insistant sur ces certifications comme obligatoire pour ce véhicule sans fournir préavis de leur nécessité semble être une condition exclusive et potentiellement préjudiciable. Nous demandons respectueusement que le Canada supprimer ces exigences du besoin et émet une Demande de propositions séparé, avec une notification en bonne et due forme, pour les sites sécurisés qui peuvent légitimement exiger ces certifications. La réponse du Canada était de (à juste titre à notre avis) de supprimer ces exigences. Le Canada a déjà supprimé l'obligation pour la certification EAL selon les Critères communs dans ce besoin, et avoir créé un précédent pour ne pas avoir besoin de AS- SIP dans la demande précédente, nous demandons que le Canada supprimer l'obligation pour elle dans celui-ci également. Page 7 de 8

8 Réponse No. 222 Les exigences demeureront inchangées. Question No. 223 À l annexe A Section 9.8 fournit une liste compréhensive des exigences liées aux contrôleurs de session en périphérie. Beaucoup de ces exigences sont uniques aux contrôleurs de session en périphérie à côté ligne et contrôleur de session en périphérie les liaisons réseau mais pas aux deux, en particulier en termes de performance de BHCA et interfaces liés au support. Plus qu'un fournisseur aborde ces différentes exigences en positionnant différents modèles de contrôleurs de session en périphérie qui se spécialisent dans les rôles respectifs, tout particulièrement à savoir la ligne côté et côté réseau des contrôleurs de session en périphérie. La combinaison de ces exigences dans une "boîte" se traduira par une solution qui probablement performera bien dans un rôle, mais mal à l'autre tout en étant rentable à aucun. Afin de permettre aux fournisseurs de présenter des propositions avec le meilleur de sa catégorie de contrôleurs de session en périphérie, est-ce que la couronne peut faire la distinction entre les rôles et fournir des exigences spécifiques au rôle? Réponse No. 223 Le choix de composantes des systèmes de téléphonie IP, nécessaire pour être conforme aux exigences connexes aux contrôleurs de session en périphérie entreprise est entièrement a la discrétion des soumissionnaires. Les soumissionnaires doivent s'assurer que tous produits requis pour être conforme à ces exigences doivent être inclus dans le formulaire 2A. Page 8 de 8