tidig Media tillstånd under vilka förhållanden bör förhandlade media flöde före 200 OK (inbjudan)? Richard Ejzak.

Presentation på tema: ”tidig Media tillstånd under vilka förhållanden bör förhandlade media flöde före 200 OK (inbjudan)? Richard Ejzak.”- Presentation transkript:

1 tidig Media tillstånd under vilka förhållanden bör förhandlade media flöde före 200 OK (inbjudan)? Richard Ejzak

 tidig Media tillstånd under vilka förhållanden bör förhandlade media flöde före 200 OK (bjud in)

2 Vad RFC säger om tidiga medier
vissa RFC antar (tidigt) media kan strömma omedelbart efter signalering SDP enligt signalerad riktning (RFC 3264) när förutsättningar uppfylls (RFC 3312) inga undantag som beskrivs för tidiga medier andra RFC beskriver förhållanden där tidiga medier inte kommer att återges RFC 3261: 180 svar ”kan användas för att initiera lokal ringback” RFC 3960: Får inte göra flera källor under forking ”en UAC bör utveckla sin lokala politik när det gäller lokal ringgenerering”

vad RFC säger om tidiga medier

3 Vad PSTN säger om tidiga medier
”svar” är vanligtvis utlösaren för att börja fakturera användare förväntar sig inte att faktureras för obesvarade samtal nätverk tillåter inte användare att utbyta data innan ”svar” den avslutande omkopplaren vanligtvis ”skär igenom” media till kallad part på ”Svar” den avslutande omkopplaren ger ”samtalsförlopp” tidiga medier till den uppringande parten det finns ingen ”avslutande omkopplare” för att Polis tidiga medier i ett typiskt SIP-nätverk Hur vet vi om tidiga medier utbyts med en auktoriserad nätverksenhet eller en slutanvändare?

 vad PSTN säger om tidiga medier

4 vissa tillämpningar av tidiga medier
spela anpassad ringsignal (CRBT) spela nätverksmeddelanden felmeddelanden vidarebefordran kö, etc. Prompt och samla add ’ l uppringning info för att bekräfta tillgängligheten av media path

 vissa tillämpningar av tidiga Media

5 lokala policyalternativ vissa implementeringar tillåter inte tidiga medier:
innan du tar emot SDP-svar (för att verifiera kontaktat mål) innan du tar emot 200 OK (bjud in) (för att ge alternativ/lokal varningsindikering) från RTP-källadress annan än fjärr-RTP-destinationsadress (kan orsaka klippning eller total mediablockering) för att göra alternativ samtalsförloppsinformation (CRBT) för att göra alternativ media/dialog (forking) när mediefunktionerna är begränsade (t. ex., parallella sessioner) att prioritera Alert-Info header media att prioritera tidig session media för att förhindra potentiellt bedrägligt utbyte av användardata när fakturering börjar med ”svar”

lokala policyalternativ vissa implementeringar tillåter inte tidiga medier:

6 vilka medier ska göras före ”svar”?
lokal ringback vid mottagande av 180 Response Alert-Info header media Early media early-session Media Media från alternativa dialoger oklart hur man prioriterar dessa olika källor flexibilitet för lokal politik behövs

 vilka media som ska göras före svaret

7 Hur stänger du av oönskade källor?
Muting av media Call HOLD (a=sendonly) svart hål adress (noll adress i erbjudandet) förutsättningar blockering (gating) av media endast nätverksalternativ när du serverar slutanvändaren SIP-enhet Acceptera mediepaket men gör inte till användaren

 så här stänger du av oönskade källor

8 problem med muting Hur vet vi erbjudarens avsikt?
varnar vi en användare när vi får inaktivt eller sendonly-erbjudande? Vilka resurser reserverar vi för sessionen? Hur vet answerer att HOLD kommer att tas bort omedelbart vid 200 OK (inbjudan)? Svart håladress bättre kan inte förvirra användarens avsikt Hur vet vi vem vi ska stänga av under gaffling? Mer mediaklippning än med mediablockering

 problem med muting Hur vet vi erbjudarens avsikt

9 problem med blockering
interaktioner med RTCP bör inte förvänta sig exakta rapporter om trafik före 200 OK (inbjudan) interaktioner med ICE kan inte identifiera källor under parallell forking

 problem med blockering

10 RFC 3960 rekommendationer tidiga medier har företräde när närvarande
annars återge ringback/Alert-Info / tidig session tills media visas andra förfaranden tillåts baserat på lokal policy Till exempel använder SIP-I tidiga medier uteslutande rekommenderade procedurer bryts ner under parallell gaffling när önskan högre prioritet för alternativa medier (t. ex., CRBT) när det är nödvändigt att kontrollera källor till tidiga medier på grund av faktureringspolicyer

RFC 3960-rekommendationer tidiga medier har företräde när de är närvarande

11 utkast-ejzak-sipping-p-em-auth-01 fokuserar på smalt problem
gäller endast för privata nätverk med transitive trust model Network som kan utföra media blocking (gating) nära UAs identifierar auktoriserade källor till tidiga medier för att undvika blockering fungerar bra med RFC 3960 eftersom auktoriserade tidiga medier alltid passerade och har företräde blockering sker nätverk kan blockera utan rubriken ingen garanti tidiga media kommer att göras

 utkast-ejzak-smuttar-p-em-auth-01 fokuserar på smala problem

12 Header Definition P-Early-Media=sendrecv-both way media allowed =sendonly-backward media allowed =recvonly-forward media allowed = inaktiv-ingen media tillåten skickas från UAS till UAC för att indikera tillstånd för tidiga Media proxyservrar kan ändra Av säkerhets-eller politiska skäl indikation på att bakåt tidigt media är godkänt med hjälp av ”sendonly” eller ”sendrecv” indikerar också remote end kommer att ge samtal framsteg media som ska återges indikation på att bakåt media inte godkänts visas med ”inaktiv” eller ”recvonly”, indikerar också att lokala slutet bör göra en annan källa kan skicka in första inbjudan att indikera stöd för rubriken

 Header Definition

13 avvisade alternativ till utkast
använd alternativtagg i obligatorisk rubrik för att indikera att tidiga medietillståndsförfaranden kan användas UAS kan begära tidiga medier men får inte få det använd alternativtagg i obligatorisk rubrik för att indikera att tidiga medier kommer att blockeras förhindrar nätverk från genomförande av policyer baserade på information i svar (måste bestämma på framsidan) Transitive trust model (fatta auktoriseringsbeslut baserat på kunskap om nästa hop-server) kanske inte gäller utanför nätverkssamtal med hjälp av någon av metoderna kommer att misslyckas om inte uas uppgraderas (inget incitament att uppgradera utanför privat nätverk) antingen modifiering förhindrar effektivt privat nätverk från att använda tillägg för att kontrollera åtkomst till tidiga medier

 avvisade alternativ till

14 blockering vid den privata nätverksgränsen
rubriken behövs inte strikt om blockering policyn implementeras på den plats där policybeslutet fattas t. ex. vid nätverksgränsen (SBC) så varför är det så kontroversiellt? Header tillåter användning av befintliga media kontrollpunkt i nätverk som IMS (at P-CSCF) Header möjliggör samtrafik utan SBC mellan betrodda nätverk genomföra olika tidiga media auktoriseringspolicyer

 blockering vid den privata nätverksgränsen

15 ytterligare problem som ska lösas?
ge medel för UAS att upptäcka om tidiga medier kommer att återges så UAS kan överväga att använda alternativa förfaranden när tidiga medier otillgängliga skulle lösa befintliga problem separat från tidig media tillstånd bör tillåta befintliga utkast för att fortsätta ger incitament för UAs kräver tillgänglighet av tidiga medier för att genomföra ny förlängning

ytterligare problem som ska lösas

Lämna ett svar

Din e-postadress kommer inte publiceras.