II.7.7- LE CORPS DU MESSAGE




Précédent
Sommaire
Suivant


Dans le cas des requêtes, un Corps de message est ajouté ou non  selon la méthode utilisée:

Méthode

Corps du message

ACK

Description de session

INVITE

Description de session

OPTIONS

Description de session

BYE

Pas de Corps de message

REGISTER

Réservé pour le futur

CANCEL

Non précisé

Dans le cas des réponses, le Corps du message est obligatoire et son type et interprétation dépendent de la méthode et des codes d’état utilisés.

Exemples :

Code 1xx : le Corps du message contient des informations nous indiquant la progression de la requête ;

Code 2xx : dans le cas d’une réponse à une requête INVITE, le corps du message contient une description de la session ;

Code 3xx : le Corps du message contient une description de destinations ou services intermédiaires ;

Code 4xx à 6xx: le Corps du message contient des informations additionnelles lisibles pour l’utilisateur et l’informant sur les causes d’erreurs ;

Le type de médium du Corps du message doit être donné par le champ d’en-tête Content-Type. Si le Corps du message a subit un codage tel que la compression (JPEG, GIF, MPEG…), cela doit être indiqué par le champ d’en-tête Content-Encoding (sinon ce champ doit être omis). La longueur du message (en octets) est donnée par le champ d’en-tête Content-Length.

Contrairement aux protocoles standards tels que IP ou TCP, où le format des paquets ou segments est bien déterminé, le format des messages SIP n’est pas standard. Les champs d’en-tête sont choisis " à la carte " selon un panelle de champs. Lorsque les messages SIP sont transportés par UDP, avec authentification et une description de session complexe, il arrive que la taille du message SIP de requête ou réponse dépasse la MTU. Pour résoudre ce problème, un format compact a été défini utilisant des abbréviations pour les champs d’en-tête suivants :

Champ d’en-tête

Abbréviation associée

Content-Type

c

Content-Encoding

e

From

f

CALL-ID

i

Contact

m(pour " moved ")

Content-Length

l

Subject

s

To

t

Via

v

Ainsi, le message d’invitation à une conférence en multicast (voir le 2ème exemple du paragraphe II.8.5):

INVITE sip:schooler@cs.caltech.edu SIP/2.0

Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348

;maddr=239.128.16.254;ttl=16

Via: SIP/2.0/UDP north.east.isi.edu

From: Mark Handley <sip:mjh@isi.edu>

To: Eve Schooler <sip:schooler@caltech.edu>

Call-ID: 2963313058@north.east.isi.edu

CSeq: 1 INVITE

Subject: SIP will be discussed, too

Content-Type: application/sdp

Content-Length: 187

v=0

o=user1 53655765 2353687637 IN IP4 128.3.4.5

s=Mbone Audio

i=Discussion of Mbone Engineering Issues

e=mbone@somewhere.com

c=IN IP4 224.2.0.1/127

t=0 0

m=audio 3456 RTP/AVP 0

Est compacté en :

INVITE sip:schooler@vlsi.caltech.edu SIP/2.0

v:SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16

v:SIP/2.0/UDP 128.16.64.19

f:sip:mjh@isi.edu

t:sip:schooler@cs.caltech.edu

i:62729-27@128.16.64.19

c:application/sdp

CSeq: 4711 INVITE

l:187

v=0

o=user1 53655765 2353687637 IN IP4 128.3.4.5

s=Mbone Audio

i=Discussion of Mbone Engineering Issues

e=mbone@somewhere.com

c=IN IP4 224.2.0.1/127

t=0 0

m=audio 3456 RTP/AVP 0

Les clients doivent être capables de mélanger des champs d’en-tête de messages courts (format normal) avec ceux de messages longs (format compact) en utilisant les mêmes requêtes. Les serveurs doivent accepter ces deux formats à la fois.