This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Matching GoP to another GoP to another GoP

0

Hi,

I have a scenario related to multiple GoPs

I have a common attribute between GOP1 and GOP2, And another attribute is common to GOP2 and GOP3 How can I match the GOPs between three GOPS and group into a GoG

Thanks

asked 18 Mar '16, 04:16

sshark's gravatar image

sshark
6●6●6●9
accept rate: 0%

In my understanding,

Gog mix {
    Member gop1 (attribute12);
    Member gop2 (attribute12, attribute23);
    Member gop3 (attribute23);
};

should do the trick if your only issue is that attribute 12 does not exist in gop3 and attribute 23 does not exist in gop1, but both attribute12 and attribute23 are sufficiently unique, i.e. exactly one value of attribute12 matches exactly one value of attribute23.

Another trouble point is that if gop1 and gop3 would come first, and gop2 after them, you'd end up with two GoGs.

(18 Mar '16, 04:46) sindy

Thanks for your hints, unfortunately attribute12 in gop1 will have multi values and attribute23 in gop2 will have multi values. Will this cause any issues ?

Actual scenario gop1 = > SIP gop2 => Diameter gop3 => RTP

SIP gives me the user for VoIP call, based on that I filter diameter. Diameter provides the RTP end point IP address

(18 Mar '16, 05:44) sshark

It is clear that in general the attribute12 will have multiple values and attribute 23 will have multiple values, but the question is whether for two calls, you can have the same attribute 12 but different values of attribute23 (or vice versa). If yes, the above suggestion will not work, as already said but maybe not clearly enough.

But let's leave out the generalisation and talk about the real case, I would expect that SIP would use the RTP endpoint IP address returned by Diameter in the SDP it would send out, so I'd extract the RTP IP (or, even better, the whole socket) from there into the "sip_session" Gop. What am I missing?

(18 Mar '16, 06:12) sindy

Let me describe in detail. Below is the architecture

        OCS (Charging)
              |
              |
Handset ---- SBC ----- Core side
              |
              |
         Media Server

Handset to SBC SIP packets are IPSec encrypted, SBC to OCS is diameter offline charging. SBC to Media Server is H248

I wanted to capture SIP, H248 and media flow from handset to Media Server, Media Server to Core side

(18 Mar '16, 06:21) sshark

I'm not sure I understand what you wanted to say.

  • if you cannot decrypt the UE to SBC SIP contents, how would you link it to the diameter packets,

  • you say you want to capture SIP between the UE and the SBC.

Based on these two premises, I suppose you can capture decrypted UE <-> SBC SIP messages on a virtual interface of the IPsec tunnel.

Now:

  • is the "media server" really a media server, i.e. the media contents for the UE originates there, or a media proxy (possibly with transcoding), i.e. the media pass through it between UE and the core?

  • is the SBC acting as a B2BUA or as a plain proxy, i.e. are the SIP call-IDs the same between the UE and the SBC and between the SBC and the core? I mean, can we have a single GoP for both SIP branches of the call or not?

What also confuses me is that before you were talking about RTP and now you are talking about H.248. Nevertheless, the RTP socket (to be) used at the media server seems to be the only common piece of information between all the four protocols (so the only candidate for a GoG key), as I suppose nothing else is inherited from SIP to H.248. So I would extract the media sockets from the SDPs sent (but not received) by the SBC (as these point to the media servers) in the sip Pdus.

(18 Mar '16, 06:54) sindy

Apologies for not making it clear, let me try again

Handset to SBC - I cannot decode SIP message, however the charging diameter interface will give the handset IP (I can also fetch source IP from ESP packets). Using this IP, I can see RTP packets from handset to media server, which is not encrypted. Towards the core network SIP and RTP is not encrypted

Media server actually does process media - transcoding/mixing etc SBC is a B2BUA

(18 Mar '16, 07:10) sshark

Cool. So we do not have a media socket but only media IP, and even this only because we suppose that the UE uses a common IP for signalling and media (I was wondering what does Diameter have to do with media IP but I believed you were using it is a kind of database interface so I thought it would be the local media address, not the remote one).

So:

  • we actually do not have the UE<->SBC SIP at all, so B2BUA or proxy doesn't matter.

  • we have the user ID from the SIP captured at core side, which we can use to pair the SIP Gop with the Diameter Gop, and on the timeline, we get the SIP Gop first (for both outgoing calls from the UE and incoming calls to the UE). The user ID is our attribute12.

  • from the Diameter Gop, we get the UE IP (attribute23) which we should see in the H.248 and RTP as the remote address.

So even if there was no other issue, already due to the fact that we do not have the complete media socket but only the IP address we must believe that the UEs are not behind a NAT so that we wouldn't see more than one UE behind a single IP, and also that an UE is not allowed to make more than a single call at a time (i.e. no call hold).

If the requirements above are fulfilled (each remote IP matches exactly one user ID and the sessions of this unique tuple do not overlap in time), the initial idea should work.

If they are not, there is no way to properly associate the SIP session with the H.248 control exchange and RTP flow by principle, as you have no piece of information allowing you to distinguish different calls from each other (in case of sessions overlapping in time) and no piece of information allowing you to tell two UEs behind the same NAT from each other.

(18 Mar '16, 07:42) sindy

Thanks for your inputs, I have few questions

  1. I do not have any condition for RTP GoP start/stop hence end up with multiple values. Because I want to capture RTP from UE to Media server and vice versa, How can I do that ? Can you suggest sample RTP GoP

  2. UEs are not behind NAT in our solution, so all UEs will have unique IP and user

(21 Mar '16, 05:30) sshark

The least important one, from the wiki: If no Gop Stop is defined, the Gop is Stopped by the same PDU by which it is started.

The first RTP packet should contain a marker, but it is only true for audio codecs and not reliable either, some implementations do not send it and if silence suppression is used, there may be multiple markers in a single RTP flow. The last packet is not identified at all.

So your only possibility is to use the UE side IP address and both ports as RTP GoP key and use the GoP timers to limit the time after the last PDU during which another one with the same key will still be added to the old Gop. While the port at UE side may be the same for two subsequent calls, it is highly unlikely that the media proxy side port would be re-used as well. Into the GoG key, you need to use only the UE side IP address. Because it is the ip.dst for one RTP direction and ip.src for the other one, you'll have to either extract ip.addr from the RTP packets and then erase the local side IP address(es) using a Transform, either already from the RTP PDUs or latest from the RTP Gops, or you would have to define "incoming" and "outgoing" RTP PDUs and extract from them ip.src or ip.dst. In either case, your mate configuration needs to contain the list of media proxy's IP addresses to be ignored.

(21 Mar '16, 05:56) sindy

Thanks again for your valuable inputs. Can you guide me in below points

  1. How to use the GoP timers to limit the exposure of capturing unwanted PDUs. Can you give an example or web source I can check this

  2. MATE does not have capability to check existing attributes and not to keep on Extracting the same value, creating multiple iterations of same attribute value ?

  3. For me to ignore the media proxy IPs, can i use subnets instead of individual IPs ?

(22 Mar '16, 06:43) sshark

  1. Although I've recently ventured to update the MATE wiki, I haven't collected any practical experience with many of its aspects yet. And I don't think anyone has ever published any examples using the "new" syntax ("new" because it is about 10 years old by now). So please have a look at the Gop definition at the wiki and try to understand the meaning of those three timers.

  2. Extract only works at the Pdu level, which means the extraction is done just once for each individual "real" PDU (a single captured frame may contain several PDUs). But during this one-shot extraction, all instances of the required protocol field which occur in the PDU are extracted. You cannot prevent them from being Extracted, but what you can do is to remove the unnecessary ones using Transform. Gop behaves different, each additional Pdu contributing to it may extend the Gop's AVPL, but remember that if an AVP on the PDU's AVPL exactly matches (i.e. both name and value are the same) an AVP the Gop's AVPL, it will not be added again. Any (attribute name, attribute value) pair may exist only once in any AVPL by definition. Each MATE Pdu object matches exactly one real PDU and has its own individual AVPL; each Gop has a single AVPL which is built from the AVPLs of the contributing Pdus, preserving the uniqueness of each AVP.

  3. MATE converts all protocol field values to text strings. So in MATE AVP match notation, a display filter rule ip.addr == 192.168.123.0/24 is, quite simply, ip_addr^"192.168.123."; however, ip.addr == 192.168.123.0/25 becomes a multi-line nightmare of exact matches (as no wildcard character or even regexp seems to be supported, so ip.addr^"192.168.123.[0-9]" does not work). So have a thorough look at the difference between processing of individual Match clauses declared within a Transform and processing of the list of Transforms which is a parameter of the Transform clause inside a Pdu or Gop declaration, and then decide what is the best way to define the media proxy addresses to be erased from the PDUs' AVPLs. If you cannot match a whole /8, /16 or /24 subnet, it may be less confusing to use ip_addr {"192.168.123.5"|"192.168.123.6"|"192.168.123.7"}.

(22 Mar '16, 07:54) sindy

Ok, I am trying to use the timer clauses into the GoPs (e.g.Lifetime) and wireshark complains syntax error. Looks like the syntax is not valid

How can I get help if some MATE syntax which are documented is not working ?

(29 Mar '16, 21:47) sshark

You cannot unless you can read the MATE C sources better than me (as I was translating the C sources into Wiki about a month ago). Please send me your MATE code and a matching capture, I'll give you my address in the next comment which I will delete as soon as I get a confirmation e-mail message from you.

(29 Mar '16, 21:52) sindy

That's the everlasting issue with writing documentation: should it repeat every bit of information many times to support Ctrl-F based reading, or should it be as brief as possible in order not to to discourage people from reading it completely?

In particular: in the PDU section of the reference manual, I've written:

The complete declaration of a PDU looks as below; the mandatory order of the diverse clauses is as shown.

(the word mandatory is highlighted only here so far)

But I forgot to copy-paste that into the Gop declaration section, and as there is no obvious reason why the order of the clauses should be fixed, you've declared the Lifetime before Extra. I don't even think there is a non-obvious reason other than simplification of the configuration parser code, but this is how MATE's configuration parser is currently implemented and I can only document it, not change it.

(30 Mar '16, 11:51) sindy
showing 5 of 14 show 9 more comments