>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...

il faut se focaliser uniquement sur la notion de peering d'interco. Il
n'est pas question de VoLTE, d'appel d'urgence, ou d'appel depuis ou vers
l'int. Ce sont des sujets bien distincts. Je bien parler d'appel de peering
entre opérateurs consentants :)

A la façon d'SS7, finalement, on se contente de faire du SIP, du RTP, et du
codec standard. Libre à toi de faire sur ton SBC du SIP=>VoLTE

>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

Faut suivre ce qui existe, la FFT a de très bon document, il faut se
calquer sur par exemple, les stats d'interco SIPI de grands...

>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).

D'où l'assos, il faut des règles strictes. Autre point le billing, mais
c'est aussi un autre sujet, tout est remis en cause avec la notion peering.
Cela revient à évoquer le financement de la dîtes asso, mais encore un tout
autre sujet. Mais je pense que le modèle doit être viable vue le cout des
interco, mais fortement fonction des volumes.

>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 ?

Il faut un tiers de confiance, et un mecanisme de confiance, cela me parait
évident, mais rien d'impossible.




Le 15 mai 2018 à 11:19, Cedric Millet (pro) <milletced....@gmail.com> a
écrit :

>  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/
>

---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à