II.8.5- EXEMPLES DE TRANSACTIONS SIP




Précédent
Sommaire
Suivant


1)Enregitrement:

Prenons le cas d’un utilisateur dont la machine (UAC/UAS), saturn, est reliée au serveur local bell-tel.com et possède l’adresse saturn.bell-tel.com. Supposons que cet utilisateur souhaite s’enregistrer, pour participer à une session SIP en multicast, auprès de son serveur SIP et recevoir les requêtes/réponses SIP sur le port UDP 3890.

Alors, le client devra envoyer le message SIP suivant au serveur local :

C->S: REGISTER sip:bell-tel.com SIP/2.0

Via: SIP/2.0/UDP saturn.bell-tel.com

From: sip:watson@bell-tel.com

To: sip:watson@bell-tel.com

Call-ID: 70710@saturn.bell-tel.com

CSeq: 1 REGISTER

Contact: <sip:watson@saturn.bell-tel.com:3890;transport=udp>

Expires: 7200

Remarquons que cet enregistrement expirera au bout de 7200 secondes, soit 2 heures. Si une invitation à une session SIP, à destination de watson@bell-tel.com, parvient au serveur local bell-tel.com, alors elle sera redirigée vers la station saturn à l’adresse watson@saturn.bell-tel.com et sur le port UDP 3890. Si l’utilisateur souhaite être joignable n’importe où il doit le préciser dans les 2 dernières lignes de son message(notons que pour cette nouvelle requête REGISTER, le numéro de séquence a été incrémenté d’une unité) :

C->S: REGISTER sip:bell-tel.com SIP/2.0

Via: SIP/2.0/UDP saturn.bell-tel.com

From: sip:watson@bell-tel.com

To: sip:watson@bell-tel.com

Call-ID: 70710@saturn.bell-tel.com

CSeq: 2 REGISTER

Contact: *

Expires: 0

De plus l’utilisateur doit préciser la nouvelle adresse où il souhaite être contacté dans la dernière ligne de son message:

 

C->S: REGISTER sip:bell-tel.com SIP/2.0

Via: SIP/2.0/UDP saturn.bell-tel.com

From: sip:watson@bell-tel.com

To: sip:watson@bell-tel.com

Call-ID: 70710@saturn.bell-tel.com

CSeq: 3 REGISTER

Contact: sip:tawatson@example.com

Maintenant, le serveur local bell-tel.com retransmettra toutes les requêtes pour Watson au serveur distant example.com en utilisant la requête URI tawatson@example.com pour le localiser. Par contre, l’utilisateur nouvellement raccordé au serveur distant devra, au préalable, envoyer une requête REGISTER au nouveau serveur local afin d’être joignable. Mais si Watson a oublié d’enregistrer sa nouvelle adresse, son secrétaire, jon.diligent peut le faire à sa place (ce cas ne figure pas sur le schéma):

C->S: REGISTER sip:bell-tel.com SIP/2.0

Via: SIP/2.0/UDP pluto.bell-tel.com

From: sip:jon.diligent@bell-tel.com

To: sip:watson@bell-tel.com

Call-ID: 17320@pluto.bell-tel.com

CSeq: 1 REGISTER

Contact: sip:tawatson@example.com

Ainsi toute requête pour Watson sera envoyée soit vers le RG(Registrar) du serveur local bell-tel.com ou vers le serveur distant example.com. Ainsi, le serveur distant(Proxy Server) transmettra la requête à l’adresse indiquée par la requête URI. Ensuite, le champ d’en-tête Max-Forwards pourra être utilisé pour restreindre l’enregistrement au serveur distant uniquement.

2)Invitation à une conférence en multicast:

Dans cette exemple, 3 stations communiquent à travers la même session SIP multicast (SIP utilise le protocole SDP-Session Description Protocol- comme format de description de la session SIP ouverte). Supposons que les 3 participants souhaitent en inviter un 4ème, schooler@caltech.edu, relié au serveur local cs.caltech.edu. L’un des participants déjà en communication, par exemple mjh@isi.edu, va adresser une requête INVITE au 4ème participant, dont la trace est la suivante :

Les champs d’en-tête Via listent les D.N.S.(Domain Name Server) traversés le long du chemin reliant l’initiateur de la requête au destinataire de celle-ci. La requête URI indique que l’invitation est adressée à schooler@cs.caltech.edu, l’adresse courante proposée par le serveur csvax.cs.caltech.edu. L’en-tête ci-dessus est suivi d’une ligne vide et du Corps du message qui contient la description de la session.

Une fois l’UAS de l'appelé contacté, il renvoie une réponse à l’UAC de l'appelant, lui signalant qu’il sonne bien ("ringing") :

S->C: SIP/2.0 180 Ringing

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> ;tag=9883472

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

CSeq: 1 INVITE

Dès que l’invité accepte de participer à la session SIP, il retourne une réponse OK précisant dans le champ d’en-tête Contact à quel PS il est relié (es@jove.cs.caltech.edu):

S->C: SIP/2.0 200 OK

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> ;tag=9883472

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

CSeq: 1 INVITE

Contact: sip:es@jove.cs.caltech.edu

Enfin, l’appelant confirme l’invitation par une requête ACK , adressée au PS précisé dans le champ d’en-tête Contact:

C->S: ACK sip:es@jove.cs.caltech.edu SIP/2.0

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

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

To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472

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

CSeq: 1 ACK

3)Appel entre 2 utilisateurs:

Dans le cas d’un appel téléphonique sur IP entre 2 utilisateurs (Bell et Watson), l’appelant (Bell) doit préciser dans son invitation quels types de média il supporte (dans notre exemple, il s’agit des types 0 (PCMU), 3 (GSM), 4 (G.723) et 5 (DVI4)) :

C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:watson@bell-tel.com>

Call-ID: 3298420296@kton.bell-tel.com

CSeq: 1 INVITE

Subject: Mr. Watson, come here.

Content-Type: application/sdp

Content-Length: ...

v=0

o=bell 53655765 2353687637 IN IP4 128.3.4.5

s=Mr. Watson, come here.

c=IN IP4 kton.bell-tel.com

m=audio 3456 RTP/AVP 0 3 4 5

S->C: SIP/2.0 100 Trying

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311

Call-ID: 3298420296@kton.bell-tel.com

CSeq: 1 INVITE

Content-Length: 0

S->C: SIP/2.0 180 Ringing

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311

Call-ID: 3298420296@kton.bell-tel.com

CSeq: 1 INVITE

Content-Length: 0

S->C: SIP/2.0 182 Queued, 2 callers ahead

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311

Call-ID: 3298420296@kton.bell-tel.com

CSeq: 1 INVITE

Content-Length: 0

S->C: SIP/2.0 182 Queued, 1 caller ahead

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311

Call-ID: 3298420296@kton.bell-tel.com

CSeq: 1 INVITE

Content-Length: 0

S->C: SIP/2.0 200 OK

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: <sip:watson@bell-tel.com> ;tag=37462311

Call-ID: 3298420296@kton.bell-tel.com

CSeq: 1 INVITE

Contact: sip:watson@boston.bell-tel.com

Content-Type: application/sdp

Content-Length: ...

v=0

o=watson 4858949 4858949 IN IP4 192.1.2.3

s=I'm on my way

c=IN IP4 boston.bell-tel.com

m=audio 5004 RTP/AVP 0 3

Cet exemple illustre bien l’utilisation des codes d’état dans les réponses que l’UAS retourne à l’UAC. La réception de l’appel par le PS auquel est relié l'appelant est confirmée par une réponse TRYING(code 100) et la sonnerie d’appel chez l’appelé par une réponse RINGING (code 180), puis 2 réponses signalent que l’appel a été mis en attente en précisant l’état de la file d’attente : "Queued, 2 callers ahead" et "Queued, 1 caller ahead" (code 182). Enfin, quand l’appelé décroche, une réponse OK le signale à l’appelant et précise quels types de média il supporte : 0 (PCMU) et 3 (GSM). Notons que Bell et Watson s’échangeront des données audio (voix sur IP par exemple). Watson les enverra vers le port d’entrée 3456 de la machine c.bell-tel.com de Bell, et Bell les enverra vers le port d’entrée 5004 de la machine boston.bell-tel.com de Watson. Si nos deux interlocuteurs n’avaient pas précisé les ports d’entrée et le protocole de transport des données, RTP et RTCP auraient été choisis par défaut car ils permettent de véhiculer d’assurer le contrôle de flux des données en temps-réel. Les paquets RTCP auraient alors été reçus par les machines de Bell et Watson sur les ports d’entrée 3457 et 5005 respectivement. Une fois que les 2 locuteurs se sont accordés sur les types de média utilisés, l’appelant confirme l’appel par une requête ACK :

C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311

Call-ID: 3298420296@kton.bell-tel.com

CSeq: 1 ACK

4)Terminer un appel:

Pour mettre fin à un appel, l’appelant ou l’appelé peut émettre un requête BYE :

C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. A. Watson <sip:watson@bell-tel.com> ;tag=37462311

Call-ID: 3298420296@kton.bell-tel.com

CSeq: 2 BYE

5)Duplication des requêtes par les PS:

Etudions le cas où Bell souhaite appeler Watson qui est " logué " sur 2 machines simultanément - X et Y - au moment de l’appel. Seulement Watson possède 4 adresses SIP enregistrées par le Registrar du même du PS (ieee.org): A (watson@acm.org), H (watson@h.bell-tel.com), X (t.watson@x.bell-tel.com) et Y (watson@y.bell-tel.com). Bell ne travaille que sur une seule station (c.bell-tel.com) à l’adresse C (a.g.bell@bell-tel.com). L’UAC auquel Bell est relié envoie une requête INVITE à Watson à l’adresse t.watson@ieee.org reconnue par le PS de nom de domaine ieee.org :

C->PS: INVITE sip:t.watson@ieee.org SIP/2.0

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>

Call-ID: 31415@c.bell-tel.com

CSeq: 1 INVITE

Le PS SIP essaie les 4 adresses de Watson en parallèle. Il envoie par exemple le message suivant à la machine H :

PS->H: INVITE sip:watson@h.bell-tel.com SIP/2.0

Via: SIP/2.0/UDP sip.ieee.org ;branch=1

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>

Call-ID: 31415@c.bell-tel.com

CSeq: 1 INVITE

Mais comme Watson n’est pas logué sur cette machine actuellement, une réponse Not Found (code 404) est retournée au PS par la station appelée :

H->PS: SIP/2.0 404 Not Found

Via: SIP/2.0/UDP sip.ieee.org ;branch=1

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>;tag=87454273

Call-ID: 31415@c.bell-tel.com

CSeq: 1 INVITE

Afin que la station H ne retransmette pas indéfiniment sa réponse, le PS lui envoie une requête ACK :

PS->H: ACK sip:watson@h.bell-tel.com SIP/2.0

Via: SIP/2.0/UDP sip.ieee.org ;branch=1

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>;tag=87454273

Call-ID: 31415@c.bell-tel.com

CSeq: 1 ACK

Parallèlement, le PS tente de contacter Watson à l’UAS des stations A, X et Y :

PS->A: INVITE sip:watson@acm.org SIP/2.0

Via: SIP/2.0/UDP sip.ieee.org ;branch=2

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>

Call-ID: 31415@c.bell-tel.com

CSeq: 1 INVITE

PS->X: INVITE sip:t.watson@x.bell-tel.com SIP/2.0

Via: SIP/2.0/UDP sip.ieee.org ;branch=3

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>

Call-ID: 31415@c.bell-tel.com

CSeq: 1 INVITE

PS->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0

Via: SIP/2.0/UDP sip.ieee.org ;branch=4

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>

Call-ID: 31415@c.bell-tel.com

CSeq: 1 INVITE

Comme cela devait arriver, Watson sur la station X et l’un de ses collègues sur la station Y entendent simultanément la sonnerie d’invitation et décrochent : X et Y renvoient simultanément une réponse OK à Bell, via le PS :

X->PS: SIP/2.0 200 OK

Via: SIP/2.0/UDP sip.ieee.org ;branch=3

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org> ;tag=192137601

Call-ID: 31415@c.bell-tel.com

CSeq: 1 INVITE

Contact: sip:t.watson@x.bell-tel.com

Y->PS: SIP/2.0 200 OK

Via: SIP/2.0/UDP sip.ieee.org ;branch=4

Via: SIP/2.0/UDP c.bell-tel.com

Contact: sip:t.watson@y.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org> ;tag=35253448

Call-ID: 31415@c.bell-tel.com

CSeq: 1 INVITE

Les 2 réponses sont simultanément retransmises à Bell par le PS alors que l’UAS de la station A n’a toujours pas répondu et cherche toujours Watson dans sa base de données. Pour lui éviter cette recherche infructueuse, le PS annule sa requête INVITE vers A, ayant obtenu des réponses positives aux requêtes envoyées aux stations X et Y. Pour cela, le PS envoie une requête CANCEL à l’UAS associée à la station A :

PS->A: CANCEL sip:watson@acm.org SIP/2.0

Via: SIP/2.0/UDP sip.ieee.org ;branch=2

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>

Call-ID: 31415@c.bell-tel.com

CSeq: 1 CANCEL

L’UAS de la station A stoppe alors sa recherche et envoie une réponse OK au PS :

A->PS: SIP/2.0 200 OK

Via: SIP/2.0/UDP sip.ieee.org ;branch=2

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>

Call-ID: 31415@c.bell-tel.com

CSeq: 1 CANCEL

Lorsque Bell reçoit les réponses à son invitation des stations X et Y, il lui faut choisir son interlocuteur parmi Watson et son collègue. Pour cela, il acquitte les 2 appels séparément afin de localiser Watson et ne conserver que l’appel lui étant destiné :

C->X: ACK sip:t.watson@x.bell-tel.com SIP/2.0

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>;tag=192137601

Call-ID: 31415@c.bell-tel.com

CSeq: 1 ACK

C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>;tag=35253448

Call-ID: 31415@c.bell-tel.com

CSeq: 1 ACK

Après avoir discuté avec Bell et son collègue, Bell sait que Watson se trouve sur la station X et envoie une requête BYE vers la station Y afin d’en terminer l’appel. La station Y confirme la fin de l’appel en envoyant à Bell (station C) une réponse OK:

C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>;tag=35253448

Call-ID: 31415@c.bell-tel.com

CSeq: 2 BYE

Y->C: SIP/2.0 200 OK

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>;tag=35253448

Call-ID: 31415@c.bell-tel.com

CSeq: 2 BYE

6) Rediriger un appel à l'aide d'un RS:

Si une autre position de Watson, enregistrée dans le RG du PS, utilise le même champ d’en-tête Contact alors le PS peut agir comme un RS et rediriger l’appel vers cette position plutôt que le faire suivre vers l’ancienne position de Watson. Pour cela, il retourne une réponse Moved Permanently (code 301) ou Moved Temporarily (code 302) à Bell (station C):

P->C: SIP/2.0 302 Moved temporarily

Via: SIP/2.0/UDP c.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: T. Watson <sip:t.watson@ieee.org>;tag=72538263

Call-ID: 31415@c.bell-tel.com

CSeq: 1 INVITE

Contact: sip:watson@h.bell-tel.com,

sip:watson@acm.org, sip:t.watson@x.bell-tel.com,

sip:watson@y.bell-tel.com

CSeq: 1 INVITE

Dans cet autre exemple, Alice (station A) souhaite renvoyer ses appels personnels vers son collègue Bob (station B), pendant son absence. Tous les appels lui étant destinés sont alors envoyés à Bob avec le champ d’en-tête TO de Alice. Si cet appel provient de Charlie (station C), alors l’UAS de la station A retourne à l’appelant une réponse Moved Temporarily (code 302) :

A->C: SIP/2.0 302 Moved temporarily

From: Charlie <sip:charlie@caller.com>

To: Alice <sip:alice@anywhere.com> ;tag=2332462

Call-ID: 27182@caller.com

Contact: sip:bob@anywhere.com

Expires: Wed, 29 Jul 1998 9:00:00 GMT

CSeq: 1 INVITE

La nouvelle requête INVITE émanant de Charlie, sera redirigée vers Bob, dont la position est déterminée grâce à une requête URI :

C->B: INVITE sip:bob@anywhere.com SIP/2.0

From: sip:charlie@caller.com

To: sip:alice@anywhere.com

Call-ID: 27182@caller.com

CSeq: 2 INVITE

Dans ce dernier exemple de redirection, Charlie (C) invite toujours Alice (A) mais toutes les requêtes issues de Charlie traversent le firewall (F) local du domaine caller.com avant d’atteindre Alice :

C->F: INVITE sip:alice@anywhere.com SIP/2.0

From: sip:charlie@caller.com

To: Alice <sip:alice@anywhere.com>

Call-ID: 27182@caller.com

CSeq: 1 INVITE

Il arrive que le pare-feu (firewall) soit saturé de requêtes et redirige alors les requêtes de Charlie vers un second serveur (S). Pour en informer Charlie, le parefeu saturé lui envoie une réponse 302 accompagnée du nom du serveur secondaire (space.caller.com) et de son port d’entrée (5080) :

F->C: SIP/2.0 302 Moved temporarily

From: sip:charlie@caller.com

To: Alice <sip:alice@anywhere.com>

Call-ID: 27182@caller.com

CSeq: 1 INVITE

Contact: <sip:alice@anywhere.com:5080;maddr=spare.caller.com>

Une fois alerté, Charlie renvoie sa requête INVITE au second serveur mais garde la même requête URI qu’auparavant :

C->S: INVITE sip:alice@anywhere.com SIP/2.0

From: sip:charlie@caller.com

To: Alice <sip:alice@anywhere.com>

Call-ID: 27182@caller.com

CSeq: 2 INVITE

7) Négociation d’une Bande Passante:

Si la requête d’un client (C) requière une Bande Passante supérieure à celle que peut supporter le canal alors le serveur (S) lui retournera une réponse Not Available (code 606) :

S->C: SIP/2.0 606 Not Acceptable

From: sip:mjh@isi.edu

To: <sip:schooler@cs.caltech.edu> ;tag=7434264

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

CSeq: 1 INVITE

Contact: sip:mjh@north.east.isi.edu

Warning: 370 "Insufficient bandwidth (only have ISDN)",

305 "Incompatible media format",

330 "Multicast not available"

Content-Type: application/sdp

Content-Length: 50

v=0

s=Let's talk

b=CT:128

c=IN IP4 north.east.isi.edu

m=audio 3456 RTP/AVP 5 0 7

m=video 2232 RTP/AVP 31

Dans sa réponse, le serveur précise alors que le débit maximum supporté par le canal est de 128 kilobits par secondes, que les seuls média supportés sont de types 5 (DVI), 0 (PCM) et 7 (LPC) pour l’audio et que le multicast n’est pas supporté.

8)Requêtes OPTIONS:

Supposons qu’un client (C) appelant souhaite connaître les capacités d’un serveur (S) appelé sans faire sonner le terminal de ce dernier. Il utilise alors une requête OPTIONS :

C->S: OPTIONS sip:bob@example.com SIP/2.0

From: Alice <sip:alice@anywhere.org>

To: Bob <sip:bob@example.com>

Call-ID: 6378@host.anywhere.org

CSeq: 1 OPTIONS

Accept: application/sdp

Et l’appelé retourne au client une description des types de média qu’il supporte. Dans ce cas, il s’agit de média audio de types 0 (PCM), 1 (1016), 3 (GSM), 99 (SX7300/8000) et vidéo de 31 (H.261), 34 (H.263) :

S->C: SIP/2.0 200 OK

From: Alice <sip:alice@anywhere.org>

To: Bob <sip:bob@example.com> ;tag=376364382

Call-ID: 6378@host.anywhere.org

Content-Length: 81

Content-Type: application/sdp

v=0

m=audio 0 RTP/AVP 0 1 3 99

m=video 0 RTP/AVP 31 34

a=rtpmap:99 SX7300/8000