First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

How does wireshark keep track of sip.call_id_generated in mgcp packets?

  • retag add tags

Sip/sdp packets contain a field sip.call_id_generated which is even kept track of in mgcp/sdp packets but cannot be found inside raw bytes of mgcp/sdp packets. How does wireshark keep track of it then?

ShahRukh's avatar
1
ShahRukh
asked 2019-10-18 07:23:56 +0000
edit flag offensive 0 remove flag close merge delete

Comments

Do you have an example capture to check this with? (captures can't be uploaded to ask.wireshark.org, but you can upload one to a public file sharing service (like onedrive, dropbox, google drive, etc) and share the link here. Please make sure there is no sensitive information in the capture file.

SYN-bit's avatar SYN-bit (2019-10-18 08:22:41 +0000) edit

Yeah here's a link to the pcap. https://drive.google.com/open?id=1Pgm...

ShahRukh's avatar ShahRukh (2019-10-18 08:47:32 +0000) edit
add a comment see more comments

1 Answer

0

Thanks for the pcap file. From looking at the packets I assume the SIP and MGCP packets are linked through the sip.call_id_generated field by inspecting the media description in the SDP part of the packets. Especially the fields sdp.connection_info and sdp.media.port.

As Wireshark uses a 2 pass dissection process, it first runs through all the packets and creates state information. In this state information, a call-id is linked to the media-ip/port from the SDP packets. Then on the second pass, the media-ip/port info in the packet will be used to retrieve the generated call-id.

So in your case, the generated call-id is created in reading the media description from packets 2 and 3 on the first pass. And then when displaying the MGCP packets (the second pass), the media description in the SDP part of the packets is the index to retrieve the generated call-id.

SYN-bit's avatar
18.5k
SYN-bit
answered 2019-10-18 09:59:23 +0000
edit flag offensive 0 remove flag delete link

Comments

Oh thanks. So this means the only reason we're seeing the generated call id in MGCP is because of Wiresharks 2 pass process. So if someone wants to trace an MGCP call manually he will have to keep track of it using sdp.connection_info and sdp.media.port?

ShahRukh's avatar ShahRukh (2019-10-18 11:26:07 +0000) edit

Not sure what you mean by manually. If you mean with tshark, then you can add the -2 option to make it do a 2-pass dissection too. With other tools you indeed need to track the call setup and rtp yourself using the IP and PORT information from the SDP part of the packets.

SYN-bit's avatar SYN-bit (2019-10-18 12:25:03 +0000) edit

Sorry for the delay. By manually I mean I am using DPDK to create my own application for recognizing calls made using MGCP but I couldn't figure out how to keep track of a single call and also the correlation between MGCP and SIP.

ShahRukh's avatar ShahRukh (2019-10-21 06:34:27 +0000) edit

As I do not have any experience with MGCP myself (other than analyzing your example), I would suggest reading the MGCP wiki page and the RFC's that are listed on that page to learn how MGCP works and interacts with SIP.

SYN-bit's avatar SYN-bit (2019-10-21 09:38:59 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer