Wireshark - filtriranje trace-a SIP2CS klica

SIP = Session Initiation Protocol
CS = Circuit Switched

Torej, voljo imam SIP2SIP in SIP2CS trace fajla, pri čemer gre pri slednjem za trace prepaid klica.
Bom sicer še sam pobrskal po netu, a vseeno - če ve kdo, kako kar najbolje filtrirati ta message ter na kaj je potrebno biti pozoren pri analizi, bom vesel. Message je namreč dolg, zato je treba narediti neko selekcijo, od kod do kod ga analizirati.

Ima kdo kako idejo?
V službi sem sicer govoril s sodelavcem, ki mi je predlagal, da se osredotočim na SIP, DIAMETER in RTP.
Najprej filtriranje SIPa, nato izris grafa toka (flow graph), zatem pa še filtriranje DIAMETRA in od točke, kjer se po avtentikaciji vzpostavi zveza, še filtriranje RTPja. Podal mi je tudi opise IPjev (application server, client, proxy CSCF..
V bistvu mi je, kot je videti, podal vse podatke na pladenj, samo me vseeno še malo matra, kako začeti analizo oz. njen opis.
Je že kdo imel izkušnjo s tem?

Lp.

-Edit: Sem v neki slovenski seminarski nalogi naletel na postopek opisa analize, tako da bo sedaj šlo, ker bom lahko sledil vzorcu.

Nisi ti še domač v IP svetu... ;)

SIP: Continuation je SIP sporočilo "100 Continue" in kot takšno seveda del zajetih podatkov in ne nekaj, kar bi Wireshark sfabriciral. Toplo priporočam, da si čim prej pogledaš kakšen kratek opis vsebine SIP spročil in protokola, da se ne boš lovil na takšnih malenkostih.

Ravno tako v IP svetu pozabi (t.j. izbriši iz spomina, ignoriraj, doživi amnezo, itd...) vse stvari, ki se tičejo ATM-ja ali drugih tehnologij. To je drug svet, ki se pokorava svojim lastnim pravilom in uporablja svoje lastne izraze.

Glede segmentacije priporočam najmanj ogled wikipedijinih člankov o TCP in UDP, kjer boš pobliže spoznal ta dva IP protokola in tudi izrazoslovje, ki se pri njiju uporablja. Hiter odgovor na tvoje splošno vprašanje se glasi: Transmission Control Protocol accepts data from a data stream, 'segments' it into chunks, and adds a TCP header creating a TCP segment. The TCP segment is then encapsulated into an IP datagram. A TCP segment is "the packet of information that TCP uses to exchange data with its peers."

Potem je to lahko tudi nadaljevanje enega sporočila, ki je bilo razrezano na več UDP (ali TCP) paketov v smislu prevelik paket za MTU povezave. Če da, potem imaš dejansko opraviti s tem, čemer se na IP-ju reče segmentacija sporočila.

Uporabi wiresharkovo funkcijo "Follow UDP (oziroma TCP) stream". To ti bo pri SIP-u zelo pomagalo.

Za "100 Trying" vs. "100 Continue" vs. "100 Try" vs. "100 Giving a Try" pa je pomembna samo številka - kar sledi številki je opisno in v RFC-ju res navedeno kot "Continue", ampak v živo vidiš vse sorte. Sam sem videl že vse štiri variante.

Konkretno v RFC:

Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF

   The Status-Code is a 3-digit integer result code that indicates the
   outcome of an attempt to understand and satisfy a request.  The
   Reason-Phrase is intended to give a short textual description of the
   Status-Code.  The Status-Code is intended for use by automata,
   whereas the Reason-Phrase is intended for the human user. A client
   is not required to examine or display the Reason-Phrase.

Zaupaj kodi...

LTFE?

Heh. Sry, da sem to tako pozno opazil, ampak niti prvi, niti drugi naslov teme mi nista bila ravno preveč privlačna.

Pri zahtevi REGISTER se pojavi "fetch bindings", nato pa še pri odgovoru OK "1 bindings".
Kako si lahko to razlagam?

Lp.

Binding:
A process associates its input or output channel file descriptors (sockets) with a port number and an IP address, a process known as binding, to send and receive data via the network.
S strani UDP ports. @ Wikipedia

Prava definicija?

Z IMS in SIP samo dva (če sprašuješ glede sodelavcev), oba sta precej zaposlena.

Evo, sem našel v oni knjigi v poglavju glede SIP:

REGISTER is used to create a binding between SIP address (Public User ID) of a user and the current UA contact address (IP address & port).

Oprosti, če bom težak kritik, ampak iz tvojega opisa je zelo težko razbrati za kaj se gre.

UA je user agent - konkretna vloga v komunikaciji, ne pa "objekt", ki bi nekaj vseboval. Naslov UA in vrata za komunikacijo so tisto, kar se povezuje, ne pa UA kot takšen. Morda bi moral najti boljši izraz, ki opisuje ta par in hkrati ni že uporabljen za nekaj drugega.

Upoštevaj tudi to, da je lahko na en "UA address, port pair" vezano tudi več URI-jev. Oziroma v IMS poimenovanju IMPU-jev in/ali IMPI-jev. In obratno, en IMPI je lahko sočasno aktiven na več povezavah, na vsak IMPI pa lahko kaže tudi več IMPU-jev.

Zdaj sem za BINDING napisal takole:

Ta izraz označuje povezavo IP naslova uporabniškega agenta (angl. UA) ter (povezovalnih) vrat (angl. port), pri čemer ima v konkretnem primeru (paketa) P-CSCF vlogo UA. Ob tem velja omeniti, da je lahko na en UA naslov ter njegova (povezovalna) vrata vezanih več IMPU-jev in/ali IMPI-jev - in obratno, en IMPI je lahko sočasno aktiven na več povezavah, na vsak IMPI pa lahko kaže tudi več IMPU-jev.

Je ok?