SIP - Le modèle offre / réponse
L'utilisation de SDP avec SIP est donnée dans la réponse d'offre SDP RFC 3264. Le type de corps de message par défaut dans SIP est application/sdp.
L'appelant répertorie les capacités multimédias qu'il est prêt à recevoir dans SDP, généralement dans un INVITE ou dans un ACK.
La partie appelée répertorie ses capacités multimédias dans la réponse 200 OK à l'INVITE.
Une utilisation SIP typique de SDP comprend les champs suivants: version, origine, sujet, heure, connexion et un ou plusieurs médias et attributs.
Les champs d'objet et d'heure ne sont pas utilisés par SIP mais sont inclus pour des raisons de compatibilité.
Dans la norme SDP, le champ sujet est un champ obligatoire et doit contenir au moins un caractère, suggéré comme s = - s'il n'y a pas de sujet.
Le champ d'heure est généralement défini sur t = 00. SIP utilise les champs de connexion, de média et d'attribut pour configurer des sessions entre UA.
Le champ d'origine a une utilisation limitée avec SIP.
L'identifiant de session est généralement maintenu constant tout au long d'une session SIP.
La version est incrémentée chaque fois que le SDP est modifié. Si le SDP envoyé est inchangé par rapport à celui envoyé précédemment, la version est conservée.
Comme le type de session multimédia et le codec à utiliser font partie de la négociation de connexion, SIP peut utiliser SDP pour spécifier plusieurs types de supports alternatifs et pour accepter ou refuser sélectivement ces types de supports.
La spécification offre / réponse, RFC 3264, recommande qu'un attribut contenant a = rtpmap: soit utilisé pour chaque champ de média. Un flux multimédia est refusé en définissant le numéro de port sur zéro pour le champ multimédia correspondant dans la réponse SDP.
Exemple
Dans l'exemple suivant, l'appelant Tesla souhaite mettre en place un appel audio et vidéo avec deux codecs audio possibles et un codec vidéo dans le SDP transporté dans l'invitation initiale -
v = 0
o = John 0844526 2890844526 IN IP4 172.22.1.102
s = -
c = IN IP4 172.22.1.102
t = 0 0
m = audio 6000 RTP/AVP 97 98
a = rtpmap:97 AMR/16000/1
a = rtpmap:98 AMR-WB/8000/1
m = video 49172 RTP/AVP 32
a = rtpmap:32 MPV/90000Les codecs sont référencés par les numéros de profil RTP / AVP 97, 98.
La partie appelée Marry répond à l'appel, choisit le deuxième codec pour le premier champ média et refuse le deuxième champ média, ne voulant qu'une session AMR.
v = 0
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110
s = -
c = IN IP4 200.201.202.203
t = 0 0
m = audio 60000 RTP/AVP 8
a = rtpmap:97 AMR/16000
m = video 0 RTP/AVP 32Si cet appel audio uniquement n'est pas acceptable, Tom enverra un ACK puis un BYE pour annuler l'appel. Sinon, la session audio serait établie et les paquets RTP échangés.
Comme cet exemple l'illustre, à moins que le nombre et l'ordre des champs multimédias ne soient conservés, l'appelant ne saurait avec certitude quelles sessions multimédias ont été acceptées et refusées par l'appelé.
Les règles d'offre / réponse sont résumées dans les sections suivantes.
Règles de génération d'une offre
Une offre SDP doit inclure tous les champs SDP obligatoires (cela inclut v =, o =, s =, c = et t =). Ce sont des champs obligatoires dans SDP.
Il comprend généralement un champ média ( m = ) mais ce n'est pas obligatoire. Les lignes multimédias contiennent tous les codecs répertoriés par ordre de préférence. La seule exception à cela est que si le terminal prend en charge un grand nombre de codecs, les plus susceptibles d'être acceptés ou les plus préférés doivent être répertoriés. Différents types de médias incluent l'audio, la vidéo, le texte, le MSRP, le BFCP, etc.
Règles de génération d'une réponse
Une réponse SDP à une offre doit être construite selon les règles suivantes -
La réponse doit avoir le même nombre de m = lignes dans le même ordre que la réponse.
Les flux multimédias individuels peuvent être refusés en définissant le numéro de port sur 0.
Les flux sont acceptés en envoyant un numéro de port différent de zéro.
Les charges utiles répertoriées pour chaque type de support doivent être un sous-ensemble des charges utiles répertoriées dans l'offre.
Pour les charges utiles dynamiques, le même numéro de charge utile dynamique n'a pas besoin d'être utilisé dans chaque direction. En général, une seule charge utile est sélectionnée.
Règles de modification d'une session
Chaque partie peut lancer un autre échange d'offre / réponse pour modifier une session. Lorsqu'une session est modifiée, les règles suivantes doivent être suivies -
Le numéro de version de la ligne d' origine ( o = ) doit être soit le même que le dernier envoyé, ce qui indique que ce SDP est identique à l'échange précédent, ou il peut être incrémenté de un, ce qui indique un nouveau SDP qui doit être analysé.
L'offre doit inclure toutes les lignes médias existantes et elles doivent être envoyées dans le même ordre.
Des flux multimédias supplémentaires peuvent être ajoutés à la fin de la liste m = line.
Un flux multimédia existant peut être supprimé en définissant le numéro de port sur 0. Cette ligne multimédia doit rester dans le SDP et dans tous les futurs échanges offre / réponse pour cette session.
Appel en attente
Un correspondant en cours d'appel peut temporairement mettre l'autre en attente. Cela se fait en envoyant un INVITE avec un SDP identique à celui de l'INVITE d'origine mais aveca = sendonly attribut présent.
L'appel est à nouveau activé en envoyant une autre INVITE avec le a = sendrecvattribut présent. L'illustration suivante montre le flux d'appels d'un appel en attente.
