Présentation sur le thème: « Autorisation préalable des médias Dans quelles conditions les médias négociés devraient-ils circuler avant 200 OK (INVITATION)? Richard Ejzak. » – Transcription de la présentation:
1 Autorisation préalable des médias Dans quelles conditions les médias négociés doivent-ils circuler avant 200 OK (INVITATION)? Richard Ejzak
2 Ce que disent les RFC à propos des médias précoces
Certains RFC supposent que les médias (précoces) peuvent circuler immédiatement après la signalisation du SDP Selon la directionnalité signalée (RFC 3264) Lorsque les conditions préalables sont remplies (RFC 3312) Aucune exception décrite pour les médias précoces D’autres RFC décrivent des conditions dans lesquelles les médias précoces ne seront pas rendus Réponse RFC 3261:180 « peut être utilisée pour initier un rappel local » RFC 3960: Ne peut pas rendre plusieurs sources pendant le forking » Un UAC doit développer sa politique locale concernant la génération de sonnerie locale »
3 Ce que dit le RTPC à propos des premiers médias
La « réponse » est généralement le déclencheur pour commencer à facturer Les utilisateurs ne s’attendent pas à être facturés pour les appels sans réponse Les réseaux ne permettent pas aux utilisateurs d’échanger des données avant de « Répondre » Le commutateur de terminaison « coupe » généralement les médias à l’appelé sur « Répondre » Le commutateur de terminaison fournit des médias précoces « progression de l’appel » à l’appelant Il n’y a pas de « commutateur de terminaison » pour police des médias précoces dans un réseau SIP typique Comment savons-nous si les médias précoces sont échangés avec une entité réseau autorisée ou un utilisateur final?
4 Certaines applications des premiers médias
Lisent la sonnerie personnalisée (CRBT) Lisent les annonces réseau Les messages d’erreur de transfert de file d’attente, etc. Demander et collecter des informations de numérotation add’l Pour confirmer la disponibilité du chemin des médias
5 Options de politique locale Certaines implémentations interdisent les premiers médias:
Avant de recevoir la réponse SDP (pour vérifier la cible contactée) Avant de recevoir 200 OK (INVITATION) (pour fournir une indication d’alerte alternative / locale) De l’adresse source RTP autre que l’adresse de destination RTP distante (peut provoquer un écrêtage ou un blocage total du support) Pour afficher les informations de progression d’appel alternatives (CRBT) Pour afficher un support / dialogue alternatif (forking) Lorsque les capacités du support sont limitées (par ex., sessions parallèles) Pour donner la priorité aux médias d’en-tête Alert-Info Pour donner la priorité aux médias en début de session Afin d’empêcher l’échange potentiellement frauduleux de données utilisateur lorsque la facturation commence par « réponse »
6 Quels médias rendre avant de « répondre » ?
Rappel local à la réception de 180 Médias d’en-tête d’alerte-Info de réponse Médias précoces Médias de première session Médias de boîtes de dialogue alternatives Pas clair comment hiérarchiser ces différentes sources Flexibilité de la politique locale nécessaire
7 Comment désactiver les sources indésirables?
Mise en sourdine du support Call HOLD (a = sendonly) Adresse de trou noir (adresse nulle dans l’offre) Conditions préalables Blocage (gating) du support Uniquement option réseau lors de la desserte du périphérique SIP de l’utilisateur final Accepter les paquets de support mais ne pas rendre à l’utilisateur
8 Problèmes de mise en sourdine Comment connaissons-nous l’intention du soumissionnaire?
Alertons-nous un utilisateur lorsqu’il reçoit une offre inactive ou envoyée uniquement ? Quelles ressources réservons-nous pour la session? Comment le répondeur sait-il que la RETENUE sera immédiatement supprimée à 200 OK (INVITER)? L’adresse du trou noir Ne peut mieux confondre l’intention de l’utilisateur Comment savons-nous qui couper pendant le bifurcation? Plus d’écrêtage des médias qu’avec le blocage des médias
9 Problèmes de blocage
Les interactions avec RTCP Ne doivent pas s’attendre à des rapports précis sur le trafic avant 200 Interactions OK (INVITATION) avec ICE Impossible d’identifier les sources pendant le forking parallèle
10 Recommandations de la RFC 3960 Le support précoce a priorité lorsqu’il est présent
Sinon, restituez le rappel / Alerte-Info / début de session jusqu’à ce que le support apparaisse D’autres procédures autorisées en fonction de la stratégie locale Par exemple, SIP-I utilise des procédures exclusivement recommandées Pour les médias précoces qui se décomposent Lors d’un bifurcation parallèle Lorsque vous souhaitez une priorité plus élevée pour les médias alternatifs (p. ex., CRBT) Lorsqu’il est nécessaire de contrôler les sources de médias précoces en raison des politiques de facturation
11 draft-ejzak-sipping-p-em-auth-01 se concentre sur le problème étroit
Applicable uniquement aux réseaux privés avec un modèle de confiance transitif Le réseau capable d’effectuer un blocage des médias (gating) à proximité du SAMU Identifie les sources autorisées des premiers médias pour éviter le blocage Fonctionne bien avec la RFC 3960, car les premiers médias autorisés sont toujours passés et ont priorité sur les objections importantes soulevées car le SAMU ne sait pas quand les premiers médias le blocage se produit Le réseau peut bloquer sans l’en-tête Aucune garantie que les premiers médias seront rendus
12 Définition de l’en-tête P-Early-Media = sendrecv – both way media allowed = sendonly-backward media allowed = recvonly-forward media allowed =inactif – aucun média autorisé Envoyé du SAMU à l’UAC pour indiquer l’autorisation pour les premiers médias Les Proxys peuvent modifier pour des raisons de sécurité ou de politique Indication que les premiers médias en arrière sont autorisés en utilisant « sendonly » ou « sendrecv » indique également que la fin distante sera fournir un support de progression d’appel qui doit être rendu Indication que le support arrière non autorisé affiché en utilisant « inactif » ou « recvonly » indique également que la fin locale doit rendre une autre source Peut envoyer une INVITATION initiale pour indiquer le support de l’en-tête
13 Alternatives rejetées au brouillon
Utilisez la balise option dans l’en-tête requis pour indiquer que des procédures d’autorisation de support précoces peuvent être utilisées Les UAS peuvent demander des supports précoces mais peuvent ne pas l’obtenir Utilisez la balise option dans l’en-tête requis pour indiquer que les supports précoces seront bloqués Empêche le réseau de la mise en œuvre de politiques basées sur les informations dans les réponses (doit décider à l’avance) Le modèle de confiance transitif (prendre des décisions d’autorisation basées sur la connaissance du serveur de saut suivant) peut ne pas s’appliquer en dehors du réseau Les appels utilisant l’une ou l’autre approche échoueront à moins que le SAMU ne soit mis à niveau (aucune incitation à mettre à niveau en dehors du réseau privé) L’une ou l’autre modification empêche efficacement le réseau privé d’utiliser l’extension pour contrôler l’accès aux premiers médias
14 Blocage à la frontière du réseau privé
L’en-tête n’est pas strictement nécessaire en cas de blocage la politique est mise en œuvre à l’endroit où la décision politique est prise, par exemple, à la frontière du réseau (SBC), Alors pourquoi est-elle si controversée? L’en-tête permet l’utilisation du point de contrôle des médias existant dans des réseaux tels que IMS (at P-CSCF) L’en-tête permet l’interconnexion sans SBC entre des réseaux de confiance implémentant différentes stratégies d’autorisation précoce des médias
15 Problème supplémentaire à résoudre?
Fournir des moyens aux SAMU de découvrir si des médias précoces seront rendus Afin que les SAMU puissent envisager d’utiliser des procédures alternatives lorsque des médias précoces indisponibles résoudraient le problème existant séparément de l’autorisation des médias précoces Devrait permettre à l’ébauche existante de se poursuivre Fournit une incitation pour les SAMU nécessitant la disponibilité des médias précoces pour mettre en œuvre une nouvelle extension
