["Michael Lum" <michael.lum@xxxxxxxxxxxxxxxxx>]

Hi Luis, thanks for responding,

> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx 
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of 
> Luis EG Ontanon
> Sent: November 25, 2008 9:25 PM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] VoIP call analysis
> 
> 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".
> 

I understand this.

> > 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.
> 

I wasn't expecting any tie in between the A-interface (Iu-CS)
signaling and MAP/TCAP.
My GSM/UMTS experience is now 4 years old so I'll ignore those.

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

Yes, I understand this.

> > 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?
> 

Yes, I understand the above.
I don't think I'm explaining myself properly.

I'm only expecting to see the signaling and call state of the one leg.

I'm trying to figure out if I should add more functionality here.

The current code (as of 1.0.4) shows Location Updates as VoIP calls.
Was this intended?

Was the SCCP associations code written for VoIP calls?


> 
> > 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
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> https://wireshark.org/mailman/listinfo/wireshark-dev
>