Quand tu sais pas avec qui tu vas parler, si t'envoies des appels vers une interco non définie, comment tu garantis que tel ou tel service va fonctionner. C'est pour ca que dans la base ENUM tu dois aussi gérer aussi la notion de services associés à un numéro/interco.
un des points à traiter est de définir les services téléphoniques que ces intercos doivent supporter : - que les appels ? - du RCS, du UUS (user to user signaling), fax, voLTE, modem ... ? - apres il y a les cas à traiter ayant des impacts techniques : appels d'urgence, masquage d'identité sur des appels en arrivée depuis l'international sans que le réseau n'est fourni un PAI/NDI, bref une identité fiable... Juste un exemple simple (qui se gère facilement mais donné à titre d'illustration) : rien que les DTMF t'as 3 facons de le faire. T'as aussi le fameux PRACK nécessaire pour l'early media, prôner par Free mais pas prôner par la normalisation FFT... Donc là on vient sur le sujet normalisation du transport SIP. Il faut aussi se mettre d'accord sur la normalisation du media (RTP + RTCP) + RTCP-XR. Qui dit interco veut dire aussi indicateurs/KPI à se mettre d'accord pour débuguer, diagnostiquer, que chacun doit supporter Alors que faire ? Le plus petit dénominateur commun, qui est donc limitant pour les services, ou au contraire faire le plus exhaustif et du coup qui transcode/ fait l'adaptation de sig ? selon quelles regles (comprendre qui favorise qui) ? Je ne dis pas que c'est pas faisable, je dis juste que ca soulève de nombreux points. Que les principaux intéressés sont les petits opérateurs (les grands/gros aiment bien le cout du service transit comme déjà évoqué par Mickael Hubert ( TA taxe d'acheminement). La base de numérotation centrale est nécessaire déjà évoquée avec l'échange précédent quand on a parlé d'ENUM. La base APNF ne contient que les sda portées. pas les tranches natives (aka base GNUM). ou alors j'ai loupé un truc. Mickael dans ton dernier post, les etapes 1 à 3, le principe de routage (je regarde en local et sinon je sors) c'est déjà ce que tu fais sans base ENUM. Et comme tu le dis/ soulève, le probleme c'est la notion de fiabilité de l'information. car si un petit malin se greffe, annonce des numeros qui ne sont pas à lui (volontairement ou non), comment savoir qui a raison ? de nombreux sujets donc 2018-05-15 11:06 GMT+02:00 Mickael Hubert <mick...@winlux.fr>: > Il n'avait pas été question, il y a quelques temps, lors d'une réunion > FRNOG justement d'un SIP...X ? Il est vrai que d'interconnecter l’ensemble > des petits entre eux est vain, mais les peering X sont là pour ça (au > niveau IP). > je n'ai sûrement pas tout les tenants et aboutissant, mais pourquoi > réinventer la roue ? Le DNS fonctionne très bien (avec peut-être un peu > plus de sécu à envisager), ENUM a été créé pour cela, pourquoi ne pas > s’appuyer la dessus. > > Je vous balance ça pêle-mêle, et c'est une vision trop minimaliste, mais > si on prend exemple sur le BGP et les peering X: > > 1) j'ai un appel à destination du 0101010101, je demande déjà à mon DNS > interne (ENUM) si je connais, est-ce mon réseau ? > 2) oui, je balance dans mon réseau ==> SBC interne qui gère le client, > pourquoi pas le client en direct... > 3) non je ne gère pas ce numéro, a qui dois-je le balancer ? ==> soit sur > une interco directe que j'ai avec tel ou tel provider, soit au peering X, > soit ma route par défaut mon transitaire voix. > > A la différence de "l'internet", le plus réaliste serait que ces échanges > DNS ne soient autorisés qu'entre les providers déclarés ARCEP et que les > mises à jour ne proviennent que d'un point central et certifié (Ex: APNF) > De plus, pas d'automatisme de création des tables de routage d'appel comme > BGP. Il faudrait que chaque provider puisse savoir quelle est la route la > plus "courte" pour joindre tel ou tel numéro en prenant en compte ses > propres interco à dispo. > > Bon c'est facile à dire... > > > Le 15 mai 2018 à 10:24, boite frnog <mailbox.fr...@gmail.com> a écrit : > >> 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/
