presentatie over het thema: “Early Media Authorization Under what conditions should negotiated media flow before to 200 OK (INVITE)? Richard Ejzak.”- Presentation transcript:
1 Early Media Authorization onder welke voorwaarden moet worden onderhandeld media flow vóór 200 OK (uitnodigen)? Richard Ejzak
2 Wat RFC ’s zeggen over vroege Media
sommige RFC’ s gaan ervan uit dat (vroege) media onmiddellijk kunnen stromen na het signaleren van SDP volgens signaled directionality (RFC 3264) wanneer aan de voorwaarden is voldaan (RFC 3312) geen uitzonderingen beschreven voor vroege media andere RFC ‘ s beschrijven omstandigheden waarin vroege media niet zullen worden weergegeven RFC 3261: 180 Response “may be used to initiate local ringback” RFC 3960: Kan niet meerdere bronnen weergeven tijdens het afsplitsen “een UAC moet zijn lokaal beleid ontwikkelen met betrekking tot lokale ringgeneratie”
3 Wat de PSTN zegt over vroege media
“antwoord” is meestal de trigger om te beginnen met factureren gebruikers verwachten niet te worden gefactureerd voor onbeantwoorde gesprekken netwerken staan gebruikers niet toe om gegevens uit te wisselen voordat “antwoord” de terminating switch meestal “snijdt door” media aan opgeroepen partij op “Antwoord” de terminating switch biedt” call progress “vroege media aan de oproepende partij er is geen “terminating switch” aan politie vroege media in een typisch SIP-netwerk hoe weten we of vroege media worden uitgewisseld met een geautoriseerde netwerkentiteit of een eindgebruiker?
4 sommige toepassingen van vroege Media
spelen custom Belting tone (CRBT) spelen netwerkaankondigingen foutmeldingen doorsturen wachtrij, enz. Vraag en verzamel add ‘ l dialing info om de beschikbaarheid van MediaPad
5 lokale beleidsopties sommige implementaties verbieden vroege media:
voordat u SDP-antwoord ontvangt (om contact met het doel te verifiëren) voordat u 200 OK (uitnodiging) ontvangt (om alternatieve/lokale waarschuwingsindicatie te bieden) van RTP-bronadres anders dan remote RTP-bestemmingsadres (kan clipping of totale mediablokkering veroorzaken) om alternatieve oproepvoortgangsinfo (CRBT) weer te geven om alternatieve media/dialoogvenster (forking) te maken wanneer de media-mogelijkheden beperkt zijn (bijv., parallelle sessies) om prioriteit te geven aan Alert-Info header media om prioriteit te geven aan early-session media om mogelijk frauduleuze uitwisseling van gebruikersgegevens te voorkomen wanneer facturering begint met “antwoord”
6 Welke media te maken voorafgaand aan “antwoord”?
local ringback na ontvangst van 180 Response Alert-Info header Media Early media Early-session media Media uit alternatieve dialoogvensters onduidelijk hoe deze verschillende bronnen prioriteit moeten krijgen flexibiliteit van lokaal beleid nodig
7 Hoe ongewenste bronnen uitschakelen?
dempen van media Call HOLD (a=sendonly) Black hole address (zero address in offer) pre-Conditions Blocking (gating) of media Only network option when serving end user SIP device Accept media packets but don ‘ t render to user
8 problemen met dempen hoe weten we de intentie van de aanbieder?
waarschuwen we een gebruiker wanneer we een inactieve of alleen send-aanbieding ontvangen? Welke middelen reserveren we voor de sessie? Hoe weet answerer dat HOLD onmiddellijk zal worden verwijderd op 200 OK (uitnodigen)? Black hole address beter kan de intentie van de gebruiker niet verwarren hoe weten we wie te dempen tijdens het forken? Meer media clipping dan met media blocking
9 problemen met blokkeren
interacties met RTCP verwacht geen nauwkeurige meldingen van verkeer voorafgaand aan 200 OK (INVITE) interacties met ICE kunnen geen bronnen identificeren tijdens parallel forken
10 RFC 3960-aanbevelingen Early media heeft voorrang wanneer aanwezig
anders render ringback/Alert-Info / early-session totdat media verschijnt andere procedures toegestaan op basis van lokaal beleid Bijvoorbeeld SIP-I gebruikt early media uitsluitend aanbevolen procedures breekt tijdens parallel forking wanneer de wens hogere prioriteit voor alternatieve media (bijv., CRBT) wanneer bronnen van early media moeten worden gecontroleerd vanwege factureringsbeleid
11 draft-ejzak-sipping-p-em-auth-01 richt zich op een beperkt probleem
alleen van toepassing op particuliere netwerken met transitive trust model Network able to performance media blocking (gating) in de buurt van UAs identificeert geautoriseerde bronnen van vroege media om blokkering te voorkomen werkt goed met RFC 3960 aangezien geautoriseerde vroege media altijd gepasseerd en heeft voorrang blokkeren gebeurt netwerk kan blokkeren zonder de header geen garantie vroege media zal worden gerenderd
12 Header definitie P-Early-Media = sendrecv-both way media allowed =sendonly-backward media allowed =recvonly-forward media allowed = inactief-no media allowed Sent from UAS to UAC to indicate authorization for early media Proxies can modify for security or policy readends indicatie dat backward early media geautoriseerd is met “sendonly “of” sendrecv ” geeft ook aan dat remote end geef oproepvoortgangsmedia die moeten worden gerenderd indicatie dat achterwaartse media die niet geautoriseerd zijn getoond met “inactief” of “recvonly”, ook aangeeft dat lokaal einde een andere bron moet weergeven kan in eerste uitnodiging sturen om ondersteuning van header
13 afgewezen alternatieven voor concept
option-tag gebruiken in de vereiste header om aan te geven dat procedures voor vroege Media-autorisatie kunnen worden gebruikt UAS kunnen vroege media aanvragen, maar krijgen het mogelijk niet gebruik option-tag in de vereiste header om aan te geven dat vroege media worden geblokkeerd voorkomt dat de uitvoering van het beleid op basis van informatie in de reacties (moet beslissen up front) – Transitief model (het maken van autorisatie beslissingen die gebaseerd zijn op kennis van de volgende hop server) kan niet van toepassing zijn buiten het netwerk gebruiken om te Bellen elke aanpak zal falen, tenzij UAS bijgewerkt (geen prikkel om te upgraden van buiten het eigen netwerk) Ofwel modificatie voorkomen op effectieve wijze een eigen netwerk van het gebruik van uitbreiding van de toegang tot begin media
14 Blokkeren op het eigen netwerk grens
De header is niet strikt noodzakelijk als het blokkeren van beleid wordt uitgevoerd op de plaats waar de beleidsbeslissing wordt genomen, bijvoorbeeld aan de netwerkgrens (SBC) dus waarom is het zo controversieel? Header maakt gebruik van bestaande media control point in netwerken zoals IMS (at P-CSCF) Header maakt interconnectie mogelijk zonder SBC tussen vertrouwde netwerken die verschillende vroege Media autorisatie beleid implementeren
15 extra probleem op te lossen?
geef UA ’s middelen om te ontdekken of vroege media zullen worden weergegeven, zodat UA’ s kunnen overwegen om alternatieve procedures te gebruiken wanneer vroege media niet beschikbaar zijn bestaand probleem afzonderlijk zou oplossen van vroege Media-autorisatie zou bestaande ontwerp door moeten laten gaan geeft UA ‘ s die beschikbaarheid van vroege media nodig hebben om nieuwe extensie te implementeren
