Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] VoIP call analysis

From: "Luis EG Ontanon" <luis@xxxxxxxxxxx>
Date: Wed, 26 Nov 2008 06:24:42 +0100
On Tue, Nov 25, 2008 at 6:51 PM, Michael Lum
<michael.lum@xxxxxxxxxxxxxxxxx> wrote:
> For calls IOS 5 uses connection-oriented SCCP in the same manner as
> BSSAP.


 The "call model" the voip-calls dialog uses is just too simplistic
for taking into account mobile call scenarios. So I used "Voip-Call"
as a synonym of "Call-Leg".

> Using the SCCP preference you mentioned is how I looked at my
> trace but there are some problems with the SCCP handling in
> voip_calls.c.
>
> - it uses SCCP Connection Request as the start of a call when that
> message
>  can be used for non-call related procedures, i.e. location updates,
> SMS, etc.

For RAN-CN these procedures are run on top of the connection-less
service ([X]UDT). For CN-CN these procedures run on top of MAP/TCAP
which uses SCCP connection-less service as well. I've never seen these
messages on top of connection oriented SCCP.

The Paging messages which are in-fact call-related are not shown by
the dialog because they are transported by connection-less service.

> I don't understand why SCCP is used in VoIP Calls for call state.

Call state is too broad to be taken into account what I attempt to do
is just to put toghether as much packets as possible for a call so
that the user finds it easier to isolate them.

> I understand how SCCP connections work and the requirement to match the
> SLR/DLR
> in the SCCP CC to tie all the messaging together, but only the upper
> protocols
> such as RANAP/IOS/BSSAP know the complete call state.

As stated before this is not completelly true, a RAN node is aware of
the complete state only the for the call-leg it is handling.

The anchor-MSC is the only one aware of the complete call state and
that cannot be easily inferred from the protocol messages it uses to
control the call.

Call-leg control information is in the application protocol (RANAP,
BSSAP) add these use one SCCP connection for one call-leg, the
connection is setup at call setup and it gets released at call release
so I used that to add call-legs to the VoIP call dialog.

The concept of call in mobile-scenarios is way too complex to be
handled by this facility, a call ususaly has several call-legs.

e.g.: one "end-user-call" that does a 2G->3G intra-MSC handover  uses:

- a BSSAP leg for the initial setup (one SCCP connection)

- another RANAP leg after hand-over(another SCCP connection)

- a MAP/TCAP session which controls the handover and transports the CP
(RANAP) for that call between ancor-MSC and drift-MSC.

- The ISUP/BICC call to transport the UP.

Things can get even more complex if we are using a split-architecture
(MSC-S + MGw).

Are the GCP contexts (megaco/h248) created in the various MGws to
handle the call to be considered part of the call?


> I thought I would want the IOS dissector to use the SCCP associations
> for
> call analysis but it doesn't seem that anybody is doing that with the
> other
> dissectors.
>
> ?

SCCP and GCP are handled differently from other protocols because I
decided to re-use the session information already gathered by the
relative dissectors instead of rewriting that code in the voip-calls
dialog or writing another dialog as a whole for this.


> Thanks.
>
> --
> Michael Lum                   Principal Software Engineer
> 4600 Jacombs Road             +1.604.276.0055
> Richmond, B.C.
> Canada V6V 3B1
> Star Solutions
> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Luis EG
> Ontanon
> Sent: November 20, 2008 10:23 AM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] VoIP call analysis
>
> if IOS5 uses the connection-less SCCP service SCCP-connection-tracking
> cannot help you.
>
> If it instead uses the Conection-Oriented SCCP service, you can take a
> look at how RANAP and BSSAP put "interesting information" into the SCCP
> data for the packet/connection.
>
> (Beware that in order to trace calls SCCP needs the "Keep Track of..."
> preference being enabled).
>
> BR
>
> Lego
>
> On Thu, Nov 20, 2008 at 7:15 PM, Michael Lum
> <michael.lum@xxxxxxxxxxxxxxxxx> wrote:
>> Hi,
>>
>> I'm looking at voip_calls.c and there is a voip_protocol_name array
>> that contains, among others, SCCP, BSSMAP and RANAP.
>>
>> How does this work for a with the following partial stack:
>>
>> BSSMAP or RANAP
>> SCCP
>> M3UA
>> ...
>>
>> ?
>>
>> I tried out one of my traces with SCCP and it sort of works.
>> Was it meant to be used with the above or for some other kind of
>> protocol layering ?
>> (I thought only "A-interfaces" used connection-oriented SCCP.)
>>
>> I say it only sort of works because SCCP can't determine a call state
>> or even imply a call is taking place.
>>
>> Should I just ignore the SCCP code eventhough IOS 5 is carried on it ?
>>
>> Thanks.
>>
>> --
>> Michael Lum                   Principal Software Engineer
>> 4600 Jacombs Road             +1.604.276.0055
>> Richmond, B.C.
>> Canada V6V 3B1
>> Star Solutions
>> _______________________________________________
>> Wireshark-dev mailing list
>> Wireshark-dev@xxxxxxxxxxxxx
>> https://wireshark.org/mailman/listinfo/wireshark-dev
>>
>
>
>
> --
> This information is top security. When you have read it, destroy
> yourself.
> -- Marshall McLuhan
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> https://wireshark.org/mailman/listinfo/wireshark-dev
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> https://wireshark.org/mailman/listinfo/wireshark-dev
>



-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan