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