Ask Your Question
0

Different versions of SIP packets on local and remote site?

asked 2020-08-05 23:25:28 +0000

Rmcgrath gravatar image

updated 2020-08-06 18:53:48 +0000

Guy Harris gravatar image

I’m facing a problem with SIP protocol, which required capturing packets from local site with WireShark and remote site with TCPDUMP. When I analyze packages and specifically Register message, I notice Contact Header differs, in local capture Contact Header figure with a character "*" and remote Contact headers it appears with a double character of "@". Both files are open with same Wireshark version. Wireshark winpcap 4.1.2 version. Can't not figure what's going on.

edit retag flag offensive close merge delete

Comments

Could you make both the local and remote capture files available, so we can look at them to try to figure out the reason for the difference?

Guy Harris gravatar imageGuy Harris ( 2020-08-06 02:30:20 +0000 )edit

Have you tried with a current version of Wireshark?
Can you add version information from wireshark -v or Help->About Wireshark

Is it possible to share the capture files (or small section with the packets of interest)?

Chuckc gravatar imageChuckc ( 2020-08-06 02:43:08 +0000 )edit

What sort of network devices are in between the local and remote site? Could they be modifying the SIP message?

grahamb gravatar imagegrahamb ( 2020-08-06 09:51:18 +0000 )edit

Sorry I couldn’t find how to reply to each and make with add a comment, is not like other forums

Could you make both the local and remote capture files available, so we can look at them to try to figure out the reason for the difference? Guy Harris ( 9 hours ago )

Have you tried with a current version of Wireshark? Can you add version information from wireshark -v or Help->About Wireshark

Answer

Unfortunately I can’t, because there is information about a SIP account access and thus is one of the most hacks on the networks. When I make the post I tried to attach screen shot but forum setting is not allowing because it demands rank level.

Version 1.6.2 (SVN Rev 38931 from /trunk-1.6)

Copyright 1998-2011 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There ...
(more)
Rmcgrath gravatar imageRmcgrath ( 2020-08-06 12:13:45 +0000 )edit

Sorry I couldn’t find how to reply to each and make with add a comment, is not like other forums

Is it possible to share the capture files (or small section with the packets of interest)? Chuckc ( 9 hours ago )

Answer

Unfortunately I can’t, because there is information about a SIP account access and thus is one of the most hacks on the networks. When I make the post I tried to attach screen shot but forum setting is not allowing because it demands rank level.

Rmcgrath gravatar imageRmcgrath ( 2020-08-06 12:14:41 +0000 )edit

To grahamb

What sort of network devices are in between the local and remote site? Could they be modifying the SIP message? No, couldn’t because one acts a UAS User agent Server and the other UAC User Agent Client I can said client is connected to Internet through private network LAN and the others is on Cloud service. From my understanding it becomes from packet capture issue, it seems a gap between TCPDUMP and WinPacp.

Rmcgrath gravatar imageRmcgrath ( 2020-08-06 12:22:28 +0000 )edit

You're using a very, very old version of Wireshark (1.6.2) that's been obsolete (and therefore unsupported) for over 7 years.

The version of WinPcap (4.1.2) is also very old, 4.1.3 came out in 2013.

Theoretically there should be no differences between the captures (you haven't provided the tcpdump version) but if you can't share the captures then there's very little support we can give, especially with an obsolete version.

grahamb gravatar imagegrahamb ( 2020-08-06 12:39:44 +0000 )edit

Commented: grahamb You're using a very, very old version of Wireshark (1.6.2) that's been obsolete (and therefore unsupported) >for over 7 years. The version of WinPcap (4.1.2) is also very old, 4.1.3 came out in 2013. Theoretically there should be no differences between the captures (you haven't provided the tcpdump version) but if you can't share the captures then there's very little support we can give, especially with an obsolete version.

Reply to: grahamb Thanks. I don’t think so is related version issue, because SIP protocol is rather more oldest as WireShark version. By the way I paste TCPDUMP version with libpcap as you requested, unfortunately I couldn’t post image information of the capture trace (could forum administrator make it possible to allow attachment files? And able to respond to who commented?).

tcpdump version 4.3.0 ...(more)

Rmcgrath gravatar imageRmcgrath ( 2020-08-06 14:32:39 +0000 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2020-08-06 18:53:17 +0000

Guy Harris gravatar image

They have differences because they're different packets.

The packet in "Local site part 1" and "Local site part 2" is from UDP port 5060 to UDP port 5060.

The packet in "Remote site part 1" and "Remote site part 2" is from UDP port 5067 to UDP port 16301.

So this has nothing to do with tcpdump vs. Wireshark or WinPcap on Windows vs. libpcap on whatever UN*X you were running on. If they were supposed to be the same packets, perhaps the packets captured on the remote side had passed through some form of gateway equipment that had modified them.

edit flag offensive delete link more

Comments

I not agree, port it refer to sip Register packet and the other is Contact information, whatever my question is regardless to Contact information because on Remote information it seem more information and Local information only a character. The only difference was on the capture software because remote and local capture have analyzed with the same WireShark. Question why have differences, by the way gateway could never make change inside of packets the only possibility could be possible by using a SBC, in this case there no SBC.

Rmcgrath gravatar imageRmcgrath ( 2020-08-06 22:54:52 +0000 )edit

The only difference was on the capture software

And the network on which you did the capturing.

Perhaps there was different traffic on the two networks. If there was, there is no reason to expect that there won't be differences in what you capture.

Clearly the packet you showed in "Local site" and the packet you showed in "Remote site" are NOT the same packet, given that the port numbers are different. If you want to convince us that the same packet looks different in the two captures, you will have to capture the same packet and show it as captured on both machines.

Guy Harris gravatar imageGuy Harris ( 2020-08-07 02:55:27 +0000 )edit

I have no clue about SIP and what can be modified by hops, but the SIP element has clearly been modified as the UDP payload (presumably the SIP message) has changed from 479 bytes to 655 bytes, so modification of the SIP data you're interested in by the intervening devices seems a much more likely possibility rather than some sort of capture issue.

grahamb gravatar imagegrahamb ( 2020-08-07 12:16:13 +0000 )edit

Reply to Guy Harris

First of all I don’t have any intention to convincing anyone, simply to found answers through this forum. Regarding to capture has been done simultaneously, it is feasible that it is not the same packet since origination from a local network and goes through the router and causes modifications in order response from remote site will return to router and not a private address.

Rmcgrath gravatar imageRmcgrath ( 2020-08-07 13:28:33 +0000 )edit

Reply to grahamb.

As Local site is connected in LAN and configuration on SIP account is related to remote site it should send and go through router and it will modified packet causing payload change. The clincher is, host send Register message and should receive server in order to response to host with a ACK message, is a basic handshaking and clearly it happens host send Register message and server have received, but don’t reply "ACK" message because it seems on Contact Header have detect a double character "@". So on local capture on Contact Header is not seems same information it only seems a “*” character, as both packets is analyzed with the same wireshark I could not found any logical reason of why it happens.

Rmcgrath gravatar imageRmcgrath ( 2020-08-07 13:44:02 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2020-08-05 23:25:28 +0000

Seen: 641 times

Last updated: Aug 06 '20