Merci Nicolas pour ton retour et ta participation,
Perso pas sur Paris, j'ai réduit au max les déplacements (trains et avions) ces
derniers temps, on se demanderait presque pourquoi ....
On a pas mal de point en commun avec ta réflexion.
Je fais un retour dès que je penses que tous ceux qui souhaitent traiter le
sujet on fait signe de la main.
Donc ceux qui ont déjà posté mais non pas expressément dit qu'il voulait se
joindre merci de lever la main.
De préférence sur mon mail avec la balise [IAV] pour des questions de
traitements automatique des mails ce serait sympa.
En plus avec le 25/05 qui arrive a grand pas il serait bien d'avoir votre
consentement explicite :)
On n'a pas forcément nom et prénom via vos mails ce serait aussi très bien de
nous communiquer les informations comme :
L'email sur lequel on va diffuser (si différent de celui identifié dans votre
mail), un pro si possible
Le nom de la boite, si c'est possible mais on comprendra très bien que certains
ne soit pas strictement dans le cadre pro de la boite sur ce sujet donc pas
obligatoire. C'est juste bien de voir avec qui on va travailler.
Le poste idem c'est toujours intéressant mais pas obligatoire.
Xavier
PS1 : H-1 pour le début de la montée en charge .... à suivre
PS2 : qui a eu une RFO (Reason For Outage) de la part d'Orange ?
-----Message d'origine-----
De : Nicolas Bougues <nico...@bougues.net>
Envoyé : mercredi 16 mai 2018 02:09
À : frnog@frnog.org
Objet : Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Bonsoir à tous,
Ca doit bien faire 10 ans que je n'ai pas posté ici mais j'ai déjà pas mal
réfléchi sur ce sujet d'interco SIP multi latérale.
Je me permets donc de vous exposer en quelques mots les principaux points sur
lesquels j'ai un avis.
D'un point de vue technique, ça tournerait autour de :
- une poignée de proxys SIP, genre Kamailio par exemple, installés de
façon géographiquement / topologiquement diversifiée, adressés en
round-robin / failover
- ces machines ne géreraient que la signalisation; le media serait routé
directement entre les SBCs des opérateurs reliés; il serait donc laissé à
l'appréciation de chaque opérateur s'il lui parait pertinent de se
contenter, pour parler avec chaque opérateur, d'une interco publique,
privée ou d'un hybride (VLAN sur un GIX, whatever)
- la signalisation serait basée sur les specs SIP FFT (qui sont
maintenant à peu près complètes et bien supportées), avec des
recommendations plus étendues en ce qui concerne le media (codecs audio
variés, video, T38...). Le SDP permet une négo pourquoi s'en priver ?
- bien évidemment un filtrage d'IPs serait réalisé, chaque opérateur
membre publiant sa liste d'IPs in/out pour sig et media, publication qui
serait utilisée par les proxies pour filtrer en input et forwarder les
appels, et diffusée aux membres pour accepter les flux media
En ce qui concerne le routage :
- pour répondre à ce que j'ai vu plus haut dans la discussion, il semble
difficile de "penser BGP" : la notion d'aggrégation (qui préside pourtant à
l'attribution de tranches de 1000 ou 10000 numéros aux opérateurs par
l'ARCEP) est complètement annihilée par la portabilité et autres exceptions
(liste de numéros en routage TDM par exemple)
- on est donc à peu près obligé d'avoir d'un côté un routage par défaut
suivant l'opérateur attributaire de la tranche, avec un lookup unitaire sur
une (voire des) base(s) d'exceptions; c'est de toute façon ce que font
aujourd'hui tous les opérateurs (ne serait-ce que parce que le préfixage
des numéros portés est facturable s'il n'est pas fait par l'opérateur
appelant)
- ces informations (tranches, portas...) sont aujourd'hui publiées sous
forme de fichiers CSV ou de web services par l'APNF, qui le fait très bien
- en ce qui concerne ENUM, c'est une belle idée sur le papier, mais j'ai
plusieurs réserves :
- ça nécessite la mise en place chez chaque acteur d'un DNS précis
et disponible; ça ne fait pas partie des choses "bien connues" chez les
opérateurs telecom, même s'ils font de la VoIP
- ça nécessite d'être mis à jour en temps réel et avec exactitude par
l'attributaire d'un numéro lors d'une porta sortante; or il n'est pas
exceptionnel qu'un attributaire ne réalise pas correctement leur part des
portas sortantes (c'est-à-dire le reroutage vers le préfixe destination);
dans un tel cas, une publication APNF par le prenant permet de régler
l'essentiel du problème à l'échelle de 24h et sans le concours du cèdant;
difficile d'imaginer revenir à un routage indirect seulement
- Numérobis, en 2002, ça rappelle quelque chose à quelqu'un ? ;)
- ma conclusion, c'est qu'il ne faut pas baser un tel projet sur
ENUM, en tous cas au départ, et que si ENUM il devait y avoir, une version
centralisée (gérée par l'APNF ou sur la base des données APNF) serait
sûrement souhaitable
- en attendant, on peut donc simplement se dire que chaque opérateur
émettant un appel vers la plate-forme est responsable d'avoir fait son
homework et d'avoir déterminé si l'opérateur qu'il cherche à joindre est
membre ou non
En ce qui concerne l'APNF :
- je connais assez bien l'APNF c'est une petite équipe de bonne volonté,
mais qui est "contrainte" dans le cadre de ses principaux membres, que sont
Orange, SFR, Bouygues et Free. Quand je parle de contrainte, cela concerne
aussi bien le scope des sujets sur lesquels ils travaillent (si ça
n'intéresse pas les gros, il est peu probable que ça arrive) que la façon
dont les sujets sont traités (je veux dire, sur un sujet potentiellement
assez délicat comme celui-là, de discussions nombreuses, de spécifications
détaillées, des consultants, de nouvelles discussions, d'appels d'offres,
etc.)... Simplement à l'image de la façon dont les choses se passent chez
ces gros opérateurs.
- j'y ai déjà évoqué un tel projet, de façon très informelle; l'idée
n'est pas nouvelle, mais c'est clairement hors du cadre de réflexion
- néanmoins, il me parait indispensable d'éviter de dupliquer les
efforts, et d'être notamment en mesure de s'appuyer sur le référentiel de
données géré par l'APNF
- or ces données ne sont pas publiques. Pour, il me semble, des raisons
bonnes (éviter de divulguer des listes d'abonnés, par ex.) et moins bonnes
(parfois un certain goût de l'entre-soi)
- on pourrait donc imaginer une association alternative, qui serait
elle-même membre de l'APNF (si les statuts de cette dernière le permettent,
à voir), ou même, simplement, que tous les opérateurs concernés soient
membres de l'APNF (on parle de 1000 EUR/an pour une adhésion de base),
s'ils ne le sont pas déjà.
En ce qui concerne les considérations économiques d'un tel effort :
- tout coûte !
- dès lors qu'on sortirait de simples débats (ça, ça ne coûte que du
temps!), il faudrait donc un modèle de financement pérenne
- il me semble que la "clef" la plus juste serait le nombre de setups
d'appels; c'est en effet à la fois :
- représentatif de l'activité d'un membre (et donc du bénéfice qu'il
tire de la plate-forme)
- "orienté coûts", si on parle de machines qui ne gèrent que de la
signalisation
- incitatif à la qualité (ASR élevé, filtrer correctement les appels
destinés à la plate-forme en amont) puisque on compterait aussi bien les
appels qui aboutissent que ceux qui échouent
- last but not least, il me semble utile, au moins dans un premier
temps, de s'affranchir de toute notion économique inter-membres (la fameuse
TA), pour des raisons de simplicité. Cela veut donc dire d'exclure les
numéros SVA
Pour ce qui concerne l'ARCEP, je pense qu'il ne faut pas attendre d'eux (et à
raison) d'effort particulier; ils sont d'abord là pour réguler, autrement dit
s'assurer que le marché va dans le sens attendu (c'est-à-dire, essentiellement,
d'assurer une saine concurrence). Je ne sais pas quel regard ils auraient sur
une telle initiative; il faudrait simplement s'assurer de ne rien faire qui
contrevienne aux diverses Décisions qui réglementent l'interconnexion (dont je
ne suis pas un éminent spécialiste).
Enfin, c'est une évidence, un tel projet n'a de sens que s'il permet, à terme,
d'agréger un volume significatif de trafic, et donc d'acteurs. On peut supposer
que les opérateurs qui ont des "divop" ne seront pas très chauds (puisque ce
serait une partie de leur marché, le transit inter-opérateur, qui disparaît).
Mais je pense que la potentielle économie de TA+transit (on parle de 0.0025
EUR/minute en moyenne) peut, à un certain point, représenter une motivation
financière suffisante. Après, il n'y a plus qu'à amorcer la pompe ;)
Voilà mes 0.02cts et un peu plus.
Pour aller de l'avant, si Xavier peut nous mettre en place une ML, ça serait
super. Moi je peux héberger toute réunion sur Courbevoie, s'il y a des
parisiens motivés.
Enfin, je serai demain matin au séminaire OWF à la Bourse, peut-être certains
d'entre vous aussi ?
Le 15 mai 2018 à 13:58, Xavier ROCA <x.r...@sipleo.com> a écrit :
> Bonjour,
>
> J'ai déjà évoqué le sujet en off avec certains d'entre vous qui sont
> dans la même logique.
> Et je me rappelle une discussion d'y a bien longtemps avec Franck SIMON.
> En échangeant sur ce que l'on faisait et une de nos envies, il a
> immédiatement dit ce serait pas mal qui y est une sorte IX pour la voix.
>
> Je vois que l'idée que l'on traine depuis bientôt huit ou neuf ans a
> de l'écho et j'en suis ravi.
> Je souhaiterai que le début de flamme devienne un vrai feu, je me
> propose de structurer le début si cela vous semble pas illégitime.
>
> En interne, on a déjà pensé plusieurs fois à cela.
> Cette après-midi, j'ai réorganisé nos plannings en interne pour
> regarder les propositions déjà faite depuis hier soir et de réfléchir
> aussi a fon sur ce sujet.
>
> Il y a déjà dans la discussion de nombreuses tête bien faite et des
> gens plein de bon sens.
> il serait bien d'avoir avec nous un spécialiste des RFC comme un
> certains Stéphane Bortzmeyer (en plus on ne voit pas bien qui a écrit
> l'exemple enum sur wiki 😊) pour nous aider dans le formalisme et nous
> faire profiter de sa super connaissance autour de cela.
>
> Déjà première étape structure le groupe de travail.
> Je propose de faire un Email en prive avec [IAV] pour
> "Interco_Voix_Alternative" en balise pour en faciliter le traitement.
> On mettra en place une ML; xwiki et autres selon vos suggestions ça le
> sujet qui risque de prendre un peu de place et ce n'est peut-être pas
> la peine de polluer cette liste qui est très utiles pour pas mal
> d'autres sujets.
>
> J'ai bien pensé a invité tout ce qui le souhaiterait à Faire un Boot
> Camp sur le sujet et d'organiser cela.
> Avec pauses et animations, faut pas abuser de trop non plus eau ou
> bière dans le Goblet ! (ou rosé si on veut du local) On a de la place
> pour cela mais on est juste en peu loin de certains après le coin est
> plutôt sympa (83) Si l'idée du format tente faut trouver la période et
> si on fait cela un week-end ou en semaine.
>
> Xavier
>
> -----Message d'origine-----
> De : boite frnog <mailbox.fr...@gmail.com> Envoyé : mardi 15 mai 2018
> 10:24 À : frnog@frnog.org Objet : [FRnOG] [MISC] Peering SIP (was
> Problème interco orange)
>
> Bonjour à tous,
>
> Je me permets de créer un nouveau sujet. En effet, je pense que Xavier
> a raison, il est temps de faire bouger les choses. La crise d'hier est
> critique sur plein de plans, combien d'appels d'urgence n'ont pas été
> routés hier ? Mais sans aller aussi loin, c'est vrai que ça n'a pas
> évolué depuis un bout de temps...
>
> J'ai cependant plusieurs questions à la liste.
>
> Pourquoi ne pas faire du peering SIP, suivant le modèle du France XI
> (un France SIPIX ?) ? Est-ce que cette question a déjà été soulevée et
> si oui quels ont été les freins ?
>
> Par modèle j'entends à la fois technique, mais aussi associatif.
>
> C'est à dire un SBC centralisé joignable en interco IP sur TH2
> permettant le routage entre opérateurs, mais aussi la proxyfication du
> RTP et pourquoi pas un nouveau modèle de billing.
>
> DNS a été soulevé, c'est bien, mais quand bien même il inutile
> d'imaginer résoudre et faire du P2P entre les SBC des "petits
> opérateurs" pour pleins de raisons (notamment sécu, qualité de l'interco)...
>
> Mais alors, comment échanger (annoncer) ses tranches SDA ? Je ne
> connais pas SIP-I mais je ne crois pas qu'une notion d'annonce existe...
>
> Faudrait-il créer ce protocole (vecteurs) ? Après tout, les solutions
> opensource sont là.
>
> Mais beaucoup plus simplement, est-ce qu’une base de données gérée par
> un tiers de confiance (l'asso) ne suffirait-elle pas à redistribué à
> ses membres les tranches connues par ce service ?
>
> Charge aux opérateurs de monter ce second trunk et d'envoyer son
> trafic selon ses routes mises à jour dynamiquement sur son SBC...
>
> Non ?
>
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
--
Nicolas Bougues
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
