DNS NAPTR a SRV záznamy u Odoriku chybí ?

[xsouku04]

Tak po ani ne 2 dnech, co jsem nebyl na Netu, je to koukám prodiskutováno a DNS záznamy doplněny.
SUPER - díky - proto všichni Odoriku fandíme

Jen 2 poznámky:

1. ty NAPTR a zejm. SRV záznamy by měly být nejen pro odorik.cz, ale i pro sip.odorik.cz, takže prosím o doplnění a bude to bez ztráty kytičky.

2. zkoušel jsem efekt u toho Jitsi - ale ačkoli mi autor ve fóru tvrdil, že to Jitsi využívá a při dostupnosti TCP ho použije, tak to tak není a je třeba to stále nastavit u SIP účtu v Jitsi ručně.

Zdravím

Ad 1.
Mám dotaz. K čemu přesně je to dobré i u sip.odorik.cz, když to funguje i bez toho ?

Ad. 2 Napadá mne, žo to možná závisí na priorite, kterou dám udp a tcp variantě. Prohodil jsem tedy priority. Pomohlo? (je to to první číslo v záznamu. Tedy prohodil jsem 100 s 200

Bylo:

Kód: Vybrat vše

[xsouku04@arch-petr2 ~]$ host -t NAPTR odorik.cz
odorik.cz has NAPTR record 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.
odorik.cz has NAPTR record 200 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz

Je:

Kód: Vybrat vše

host -t NAPTR odorik.cz
odorik.cz has NAPTR record 100 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.
odorik.cz has NAPTR record 200 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.

[kapetr]

Dobrý den,

ad 1. je to dobré i u Odoriku na to, aby se zvýšila kompatibilita/komfort s všemožnými klienty a navíc, jak už uvedl i cz-helper zde: http://forum.odorik.cz/viewtopic.php?f=7&t=1154#p6989 tak když to neškodí, ale někdy někde pomůže, tak proč ne. Tím spíše, že jde o standardizovanou záležitost okolo SIP služeb.

Navíc - jistě by bylo nepěkné, aby kdyby člověk dal jako sip server odorik.cz, tak to díky NAPTR/SRV fungovalo, a kdyby dal sip.odorik.cz, tak ne. Proto se domnívám, že by záznamy NAPTR/SRV měly být i u sip.odorik.cz. Ne každý váš klient asi luští záznamy packet-snifferu a píše do devel fór - naopak očekává určitou blbuvzdornost služby - push and play.

ad 2. ANO přesně jste na to kápl. Jak jsem se informoval na fóru JITSI, tak cituji:

If the NAPTR record is telling
us your provider has a preference for TCP, we use it. Otherwise we just
do what they ask us to.

The case where TCP will be picked up automatically is when there

1. When the NAPTR record announces it as the preferred transport
2. When there is no NAPTR record and an SRV record for TCP exists.

takže jsem to otestoval - a ... to funguje to - tedy i bez nutnosti ruční konfigurace (zmenšení INVITE paketu odebráním funkcí a kodeků nebo explicitní volbou TCP pro službu Odorik) se díky NAPTR s preferencí TCP Jitsi ještě dotáže na SRV _sip._tcp.odorik.cz. a to pak i použije.

Takže pokud vám TCP pro signalizaci nevadí (např. vyšší overhead) tak by to takhle asi bylo lepší. Leda jestli nehrozí naopak jiná rizika ? Do JITSI jsem nicméně napsal, že když vědí o možném problému s fragmentací jejich velkých INVITE UDP paketů, tak by měli použít TCP, je-li dostupný, bez ohledu na preferenci v NAPTR.

Zdravím a děkuji za skvělý feedback --kapetr

[cz-helper]

Tak po ani ne 2 dnech, co jsem nebyl na Netu, je to koukám prodiskutováno a DNS záznamy doplněny.
SUPER - díky - proto všichni Odoriku fandíme

Jen 2 poznámky:

1. ty NAPTR a zejm. SRV záznamy by měly být nejen pro odorik.cz, ale i pro sip.odorik.cz, takže prosím o doplnění a bude to bez ztráty kytičky.

2. zkoušel jsem efekt u toho Jitsi - ale ačkoli mi autor ve fóru tvrdil, že to Jitsi využívá a při dostupnosti TCP ho použije, tak to tak není a je třeba to stále nastavit u SIP účtu v Jitsi ručně.

Zdravím

zkusim reagovat:

1) zalezi na implementaci, ale pokud volate na "odorik.cz", tak by melo byt dostatecne to co je, tedy NAPTR odkazujici na SRV a SRV s informaci kde a na jakem portu bezi za sluzba. Co se "sip.odorik.cz" tyce, mohl by tam teoreticky byt take ten NAPTR zaznam, ale pokud nebude, MEL by klient skusit najit A (pripadne AAAA) zaznam a "zkusit" vychozi port pro sluzbu, v tomto pripade 5060, cimz padem by to melo slapat i bez NAPTR zaznamu (i kdyz je pravda, ze se pravdepodobne zkusi nejdrive UDP).

pozn.: NAPTR zaznam muze odkazovat jak na SRV zaznam ("s"), tak na A (prip. AAAA) zaznam ("a"). Proto i s "pouze" A zaznamem by to melo slapat. NAPTR zaznam nabizi moznost "upravy" struktury dotazu, sdeleni priority sluzby nebo "presmerovani" na jinou adresu jako v pripadne odorik.cz.

2) opet zalezi na implementaci.

Kód: Vybrat vše

    odorik.cz IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.
    odorik.cz IN NAPTR 200 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.

tady je jednoznacne receno, ze ma byt bran UDP. Je to definovano tak, ze pokud se najde shoda, nemel by jiz klient pokracovat ve zjistovani zadne dalsi polozky, ktera by mela vyssi poradi (prvni cislo - 100 a 200). Pak by se meli resit "jen" preference sluzeb (to druhe cislo, pricemz cim mensi tim lepsi). Pokud klient vznese dotaz ve kterem je mu "jedno" jestli je to udp, nebo tcp, tak by mel pri nastaveni vyse vzdy vzit UDP. TCP by bylo uplatneno, pouze pokud by se ptal primo na tcp zaznam. Nemelo by pomoci ani nastaveni "preferenci" v ramci klienta. Aby mohl klient "preferovat" tcp pred udp, musel by zaznam vypadat napr. takto:

Kód: Vybrat vše

    odorik.cz IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.
    odorik.cz IN NAPTR 100 51 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.

V tomto pripade by mohlo nastaveni preferenci klienta "prebit" nastaveni v DNS a mohlo by byt uprednostneno TCP, nebot preference je doporucena cast v ramci vyberu, kde na zaklade hodnoty v DNS poskytovatel sluzby sdeluji, co uprednostnuje, ale volba je ve finale na klientovi (tedy muze se vzit tcp, ackoli ma "horsi" preferenci).

[cz-helper]

Bylo:

Kód: Vybrat vše

[xsouku04@arch-petr2 ~]$ host -t NAPTR odorik.cz
odorik.cz has NAPTR record 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.
odorik.cz has NAPTR record 200 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz

Je:

Kód: Vybrat vše

host -t NAPTR odorik.cz
odorik.cz has NAPTR record 100 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.
odorik.cz has NAPTR record 200 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.

Vetsinou jsem narazil na jednoznacnou preferenci UDP, proto jsem v puvodnim prispevku nechal ruzne poradi (100,200). Nicmene vzhledem k vyvoji vlakna bych dal jeste jednu poznamku. Navrhoval bych zachovat oboje na stejnem poradi (prvni cislo) a "jen" rozdelit preference (druhe cislo) podle toho co preferujete. Jak bylo zmineno v mem predchozim prispevku, preference je "doporuceni" ze strany poskytovatele, ale nemusi byt dodrzeno, ale poradi je zavazne, takze pokud jedno bude mit 100 a druhe 200, to s 200 se vezme jen pri dotazu na ten konkretni typ neni-li tento typ jiz i pri nizsim poradi. Teoreticky by se vyzsi hodnota poradi jeste mohla vzit pri nedostupnosti (neco jako MX zaznam pro zalozni server elektronicke posty).

To sjednoceni poradi bych radeji videl kvuli pripadnym "nekorektnim" implementacim, kdy by se klient "zasekl" na poradi 100 a tam by byl "jen" TCP zaznam. Pokud by tam bylo oboje, tedy i v pripade preference TCP, stejne by si mel byt klient schopen vybrat UDP, neumel by TCP. Pokud se to nesjednoti potencialne se muze objevit skupina klientu, ktera "pohori" (pripustime-li ze ne vsichni musi implementovat veci tak, jak jsou definovany ).

Pokud odorik.cz preferuje jako poskytovatel sluzby udp pred tcp, doporucil bych nastavit:

Kód: Vybrat vše

odorik.cz IN NAPTR 100 51 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.
odorik.cz IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.

Pokud preferuje odorik.cz tcp pred udp, doporucil bych nastavit (v tomto pripade by se chovani klientu melo shodovat s citovanym stavem):

Kód: Vybrat vše

odorik.cz IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.
odorik.cz IN NAPTR 100 51 "s" "SIP+D2U" "" _sip._udp.odorik.cz.

Jestli je to pro odorik.cz uplne jedno, nastavil bych:

Kód: Vybrat vše

odorik.cz IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.
odorik.cz IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.

V poslednim pripade je ciste na klientovi, co preferuje a ze strany poskytovatele neni zadny naznak preference mezi variantami.

V kazde ze zminenych variant by teoreticky klient mohl zvolit TCP, pokud by byla velikost paketu vetsi nez velikost UDP paketu. Nicmene to je jiz vlastnost, ktera by vyzadovala proaktivni pristup ze strany vyvojaru SW, nikde neni receno, ze by to tak muselo byt.

Jak by se k te treti variante postavilo jitsi nevim, to by se muselo vyzkouset. Nicmene podle:

zkoušel jsem efekt u toho Jitsi - ale ačkoli mi autor ve fóru tvrdil, že to Jitsi využívá a při dostupnosti TCP ho použije, tak to tak není a je třeba to stále nastavit u SIP účtu v Jitsi ručně.

by v pripade treti varianty mohl take vybrat TCP. Ale to je opravdu na vyzkouseni. Teorie obcas nesouhlasi s praxi .

[cz-helper]

Když už se tu tak naťukly ty různé metody "neautorizovaných" hovorů, jejichž identifikaci označuje Odorik v CLI informaci předponou uri_, bylo by prosím možné u hovorů z peeringswitche AODT (tedy z IP 84.19.64.170) odstranit tento příznak "nedůvěryhodnosti"?

Jiný než jiným operátorem ověřený CLIP odtud totiž zaručeně nepřijde (tedy pokud ho náhodou nepošlu já nebo "root",ze "služebního" rozhraní při testování, jako vlastní identifikaci....).

Zdravim,
kdyz uz se zde uvedlo peeringswitch. Jiz delsi dobu se snazim dostat informaci napr. z 802.cz jestli je nejaka moznost dovolat se do jejich site "z venku". V tuto chvili vim o par sitich, kam (a jak) to jde, ale 802.cz mezi ne nepatri... Neuvazuje, pripadne neprovozuje aodt nejakou proxy/gw, ktera by byla dostupna z venku a treba s nejakym prefixem k cislu / jmenu by umoznovala dovolat se do siti, ktere se "schazeji" ve switchi aodt ?

Pohybuji se ruzne i mimo hranice CR a kdyz dojde rec na VoIP, ne zcela lehko se vysvetluje, proc neni mozne se dovolat na nejaka cisla primo / pres proxy, kdyz je to vlastne "ta" skvela technologie... V podstate vecny dotaz, bohuzel .V podstate to je ve finale proti operatorum, kteri se tak rozhodli. I kdyz pritomnosti tech "par" rozumnych, mezi ktere odorik.cz patri se ponekud lepe da odpovedet. Nicmene stale je dosti cisel, ktere jsou z meho pohledu stale "nedostupne".

Predem diky za jakoukoli odpoved. Pripadne jestli je to neco slozitejsiho / delsiho, klidne muzeme pokracovat i jinymi kanaly, napr. e-mailem.

[kapetr]

Díky cz-helper za vysvětlení - o dvouúrovňovosti preferencí služeb jsem ani nevěděl. Jen mě není jasné (jak jste myslel "to s 200 se vezme jen pri dotazu na ten konkrétni typ "), nač by bylo uvádět 2 záznamy s rozdílnou 1. preferencí (to 100 x 200), pokud by dle nějaké normy (?) musel klient stejně použít jen to s (100).
Nicméně je-li to jak říkáte, tak by bylo lepší (100-50, 100-50/1) než (100-50, 200-50)

Ještě k tomu záznamu pro sip.odorik.cz. Myslel jsem z uvedených důvodů, že záznam by tam (byť sám na sebe) měl být, aby to fungovalo ať v klientovi dám jako server odorik.cz i sip.odorik.cz. Pokud bych totiž dal rovnou sip.odorik.cz, tak se klient nezeptá na NAPTR/SRV nadřízené domény odorik.cz, ale zeptá se na recordy toho udaného sip.odorik.cz. A pokud je nemá, tak je to v pytli - o TCP se z DNS klient nedoví.

[cz-helper]

Díky cz-helper za vysvětlení - o dvouúrovňovosti preferencí služeb jsem ani nevěděl. Jen mě není jasné (jak jste myslel "to s 200 se vezme jen pri dotazu na ten konkrétni typ "), nač by bylo uvádět 2 záznamy s rozdílnou 1. preferencí (to 100 x 200), pokud by dle nějaké normy (?) musel klient stejně použít jen to s (100).
Nicméně je-li to jak říkáte, tak by bylo lepší (100-50, 100-50/1) než (100-50, 200-50)

Trochu jsem to natukl / pripustil v tom pozdejsim prispevku (http://forum.odorik.cz/viewtopic.php?f= ... 7074#p7066), kdy jsem zminil e-mailovy system. Zaroven jsem tam i nadhodil moznosti nastaveni, aby bylo sjednoceno poradi a rozlisily se sluzby "pouze" preferenci. Zacnu se sjednocenim terminologie. Abychom mluvili o stejnem "cisle", take prvni z nich nazyvejme poradi (order) a druhe preferenci (preference) - vychazi z definice NAPTR (http://www.ietf.org/rfc/rfc2915.txt).

Tu vyssi hodnotu vezme pouze, pokud se mu nepodari navazat spojeni na hodnotach ziskanych ze zaznamu s nizsim poradim. Pouziva se to prakticky i u MX zaznamu, ktere slouzi pro e-mailovou komunikaci. Takze pokud bych mel zaznamy napr.:

Kód: Vybrat vše

domena.tld IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.domena.tld.
domena.tld IN NAPTR 200 50 "s" "SIP+D2U" "" _sip._udp.zaloha.domena.tld.

V tomto pripade, pokud bude mozne navazat komunikaci na adrese a porte, ktera bude odpovidat srv zaznamu pro _sip._udp.domena.tld., nemel by se druhy zaznam vubec pouzit... Pokud by se ale stalo, ze z jakehokoli duvodu by se nepovedlo navazat spojeni (napr. udrzba serveru, technicka zavada...), v tom pripade muze klient pokracovat na dalsi zaznam s vyssim poradim, tedy _sip._udp.zaloha.domena.tld. .

Kód: Vybrat vše

domena.tld IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.domena.tld.
domena.tld IN NAPTR 100 51 "s" "SIP+D2T" "" _sip._tcp.domena.tld.
domena.tld IN NAPTR 200 50 "s" "SIP+D2U" "" _sip._udp.zaloha.domena.tld.

V tomto pripade by se mela navazat komunikace nejdrive skrze _sip._udp.domena.tld. pripadne _sip._tcp.domena.tld.. Nezadari-li se, mela by se zkusit dalsi moznost na stejnem poradi (100) a pripadne az pak zkouset dalsi poradi, tedy az po vycerpani udp a tcp na _sip.x.domena.tld. se teprve muze uvazovat ten zaznam ...zaloha...
Samozrejme, pokud by klient podporoval pouze udp, tak by se zaznam na tcp mel zcela ignoroval, jako by nebyl definovan.

No a k tomu "dotazu na konkretni typ" jsem mel na mysli tuto situaci:

Kód: Vybrat vše

domena.tld IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._tcp.domena.tld.
domena.tld IN NAPTR 200 50 "s" "SIP+D2U" "" _sip._udp.domena.tld.

Rekneme, ze klient koretkne resi poradi i preferenci (tedy staci nam poradi ) a umi jen udp. Jestlize vznese dotaz do DNS, tak by mel vzit primo ten zaznam s poradim 200, nebot pro poradi 100 neni zadny "vyhovujici" zaznam, tedy zadny s UDP, ktery umi. Ten "konkretni" zaznam je v tom pripade dotaz na UDP.

Tady je ovsem potreba, aby neskoncil s tim, ze na 100 neni nic, cemu rozumi. Coz by spravne nemel, ale... Radeji je lepsi mit oboje na stejnem poradi a resit jen preference, pak si klient muze vybrat i "nerespektovat". Definice primo rika, ze poradi MUSI respektovat, ale preference by MEL respektovat => pripousti se, ze preference muze prebit svojim prednastavenim.

Ještě k tomu záznamu pro sip.odorik.cz. Myslel jsem z uvedených důvodů, že záznam by tam (byť sám na sebe) měl být, aby to fungovalo ať v klientovi dám jako server odorik.cz i sip.odorik.cz. Pokud bych totiž dal rovnou sip.odorik.cz, tak se klient nezeptá na NAPTR/SRV nadřízené domény odorik.cz, ale zeptá se na recordy toho udaného sip.odorik.cz. A pokud je nemá, tak je to v pytli - o TCP se z DNS klient nedoví.

Takto postaveno je to prakticky presne receno. Bez NAPTR/SRV zaznamu pro sip.odorik.cz skutecne nebude zkoumat, jestli existuje odorik.cz, ale rovnou se pokusi najit alespon A nebo AAAA zaznam. V pripade sip.odorik.cz bude uspesny alespon pro A. Pokusi se navazat spojeni na 5060 UDP.

Pokud chceme pripustit tcp spojeni, bylo by asi vhodne tyto zaznamy take definovat. Je mozne odkazovat vsechny NAPTR zaznamy na stejne SRV zaznamy.

Kód: Vybrat vše

odorik.cz IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.
odorik.cz IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.
sip.odorik.cz IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.
sip.odorik.cz IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.

pripadne

Kód: Vybrat vše

odorik.cz IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._tcp.sip.odorik.cz.
odorik.cz IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.sip.odorik.cz.
sip.odorik.cz IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._tcp.sip.odorik.cz.
sip.odorik.cz IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.sip.odorik.cz.

at tak nebo tak je samozrejme potreba definovat prislusny SRV zaznam. Prvni varianta vychazi z jiz existujicich SRV zaznamu.

Samozrejme je mozne definovat kazdy SRV zaznam extra:

Kód: Vybrat vše

odorik.cz IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.
odorik.cz IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.
sip.odorik.cz IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._tcp.sip.odorik.cz.
sip.odorik.cz IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.sip.odorik.cz.

Pro doplneni SRV zaznam je definovan v http://www.ietf.org/rfc/rfc2782.txt. Cisla jsou zde definovany jako priorita (priority) a (relativni) vaha (weight). Prvni z nich ma obdobny vyznam jako poradi u NAPTR. Druhe cislo je "relativni" vaha. Pokud by byly napr. 2 zaznamy se stejnou prioritou, pricemz prvni by mel vahu 60 a druhy 40, mel by byt prvni vyuzivan v cca 60% dotazu (6/10) a druhy ve 40% dotazu (4/10).
takze by to mohlo byt

Kód: Vybrat vše

_sip._udp.odorik.cz.	IN	SRV	0 0 5060 sip.odorik.cz.
_sip._tcp.odorik.cz.	IN	SRV	0 0 5060 sip.odorik.cz.

prip.

Kód: Vybrat vše

_sip._udp.odorik.cz.	IN	SRV	0 0 5060 sip.odorik.cz.
_sip._tcp.odorik.cz.	IN	SRV	0 0 5060 sip.odorik.cz.
_sip._udp.sip.odorik.cz.	IN	SRV	0 0 5060 sip.odorik.cz.
_sip._tcp.sip.odorik.cz.	IN	SRV	0 0 5060 sip.odorik.cz.

Soucasna priorita a vaha je take v pohode - priorita 4 a vaha 10.

[kapetr]

Opět - a určitě nejen za sebe - děkuji kolegovi cz-helper za vyčerpávající vysvětlení a analýzu.

Snad tedy můžeme doufat, že to někdo z adminů dle vámi uvedeného upraví
Tedy NAPTR pro odorik.cz i sip.odorik.cz s (TCP 100-50, UDP 100-50).
Jsem zvědav, zda Jitsi opravdu TCP pak zvolí automaticky.

Snad ještě - dle https://sip.cesnet.cz/cs/cesnet/howto existuje typ záznamu i pro SIPS. Vzhledem k tomu, že ho Odorik (od září ?) už také podporuje, tak by se obdobně do NAPTR/SRV mohl také přidat.

[cz-helper]

Snad ještě - dle https://sip.cesnet.cz/cs/cesnet/howto existuje typ záznamu i pro SIPS. Vzhledem k tomu, že ho Odorik (od září ?) už také podporuje, tak by se obdobně do NAPTR/SRV mohl také přidat.

Dekuji za pripomenuti.

To je definovane v SIP - http://www.ietf.org/rfc/rfc3263.txt.

Pokud bych vysel z predpokladu, ze sifrovane spojeni je narocnejsi na zdroje, dalo by se predpokladat, ze nebude stejne preferovane jako nesifrovane.
jednalo by se o tyto zaznamy:

Kód: Vybrat vše

odorik.cz. IN NAPTR 100 51 "s" "SIPS+D2T" "" _sips._tcp.odorik.cz.
sip.odorik.cz. IN NAPTR 100 51 "s" "SIPS+D2T" "" _sips._tcp.sip.odorik.cz.

_sips._tcp.odorik.cz. IN SRV 0 0 5061 sip.odorik.cz.
_sips._tcp.sip.odorik.cz. IN SRV 0 0 5061 sip.odorik.cz.

Cele dohromady by to tedy mohlo byt:

Kód: Vybrat vše

odorik.cz. IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.odorik.cz.
odorik.cz. IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._tcp.odorik.cz.
odorik.cz. IN NAPTR 100 51 "s" "SIPS+D2T" "" _sips._tcp.odorik.cz.
sip.odorik.cz. IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.sip.odorik.cz.
sip.odorik.cz. IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._tcp.sip.odorik.cz.
sip.odorik.cz. IN NAPTR 100 51 "s" "SIPS+D2T" "" _sips._tcp.sip.odorik.cz.

_sip._udp.odorik.cz. IN SRV 0 0 5060 sip.odorik.cz.
_sip._tcp.odorik.cz. IN SRV 0 0 5060 sip.odorik.cz.
_sips._tcp.odorik.cz. IN SRV 0 0 5061 sip.odorik.cz.
_sip._udp.sip.odorik.cz. IN SRV 0 0 5060 sip.odorik.cz.
_sip._tcp.sip.odorik.cz. IN SRV 0 0 5060 sip.odorik.cz.
_sips._tcp.sip.odorik.cz. IN SRV 0 0 5061 sip.odorik.cz.

Pokud se to takto nastavi, nemel by byt zadny problem plynouci z DNS zaznamu... Kazdopadne plati varianty preferenci, ktere jsem zminoval o par prispevku drive (http://forum.odorik.cz/viewtopic.php?f= ... 7085#p7066).

Pozn: snad jsou porty v pohode - nasel jsem na foru, ze pro sifrovane spojeni u odorik.cz by mel byt aktualni port 5061 pripadne jeste 6689 (http://forum.odorik.cz/viewtopic.php?f= ... sips#p5316).

[ViR]

Zdravim, kdyz uz se zde uvedlo peeringswitch. Jiz delsi dobu se snazim dostat informaci napr. z 802.cz jestli je nejaka moznost dovolat se do jejich site "z venku".

Není a nevěřím, že někdy bude. Tedy přímo. Jedině oklikou, přes některý peering.

V tuto chvili vim o par sitich, kam (a jak) to jde, ale 802.cz mezi ne nepatri... Neuvazuje, pripadne neprovozuje aodt nejakou proxy/gw, ktera by byla dostupna z venku a treba s nejakym prefixem k cislu / jmenu by umoznovala dovolat se do siti, ktere se "schazeji" ve switchi aodt ?

Ne. Tohle AODT na peeringswitchi neumožňuje a nikdy ani umožňovat nebude. Důvod je prostý. Peeringové propojení asociace je součastí "veřejně dostupné telefonní služby" (VDTS) ve smyslu ZoEK, a každý provozovatel/operátor jakékoli části VDTS je odpovědný za identifikaci (respektive identifikovatelnost) hovoru, který do VDTS vstoupí (s jistými zákonem danými výjimkami).

Z pohledu peringswitche AODT pak za identifikaci a dohledatelnost původu každého hovoru odpovídá ten operátor, který jej tam odeslal. A peeringsewitch považuje každý zprostředkovaný hovor za "důvěryhodný", stejně jako operátoři, kteří jej od AODT přijmou.

Pokud by však byl umožněn vstup "anonymních hovorů" přimo do tranzitní ústředny, byla by důvěryhodnost (a identifikovatelnost) zásadním způsobem narušena. Dokud nenastane nějaký problém, celkem o nic nejde, neboť kde není žalobce, není soudce. Ale v okamžiku, kdy by k účastníkovi nějaké připojené sítě (např. IPEXu) přišel z peeringswitche hovor se standardní identifikací a závadným obsahem, např. že na městském úřadu ve Strakonicích je bomba, a my bychom nebyli schopni uvést zdroj s údaji dle požadavků ZoEK a prováděcích vyhlášek, máme velký problém a na krku "správní delikt".

Pokud nám takový hovor pošle člen/operátor, bude na něm, aby zdroj toho problémového hovoru příslušným institucím sdělil. AODT pouze podá informaci, od koho a kdy ten hovor přišel. Tedy že původní sítí/službou je například Odorik. Je jeho věcí, jak si zpracuje a odfiltruje "důvěryhodné" a "nedůvěryhodné" hovory. Ale za to, co případně posílá dál do VDTS, prostě ručí.

Pravda je, že Odorik toto u sebe (jak strukturou sítě, tak identifikaci hovorů v ní) má celkem slušně ošetřeno. Ale je také pravda, že někteří členové AODT (IPEX, Fayn...), kteří dříve vstup neautorizovaných hovorů do svých sítí umožňovali, po zvážení rizik a přínosů tuto možnost silně omezili, respektive zrušili... (Což neznamená, že to neumožňují některým účastníkům. Ale s tím, že takový účastník výslovně bere na vědomí, že takový přichozí hovor, např. na základě ENUM, je hovorem mimo VDTS a operátor za něj žádným způsobem nezodpovídá...)

Predem diky za jakoukoli odpoved. Pripadne jestli je to neco slozitejsiho / delsiho, klidne muzeme pokracovat i jinymi kanaly, napr. e-mailem.

Není třeba používat jiné kanály .