You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have attached a pcap where in there are RTP packets inside the TURN channel Data, but when i process this the library flags the master-protocol as STUN and APP-Protocol as ViberVoip. But lets say in cases, where there is RTP inside TURN channel OR there is RTP inside STUN(generally as part of DATA attribute, which we see for Skype and Teams calls) can we have a way where in we can flag the packet as the containing RTP data. i mean any attribute i can access which tells me this?....I have attached both viber and skype pcaps.
Also, in the viber pcap we can see that flow assigned as STUN and after than same flow is assigned as DTLS. Any reason for this?...
Also, in some cases we see that even though the 4-tuple is not matching, then also the library is able to identify the flow as some voip call. Just, wanted to understand how does the processing takes place here, is it based on flow OR the library records something like IP and Port and then tries to check in flows??... Example is below
Please help in clarifying the above two scenarios.
The text was updated successfully, but these errors were encountered:
I have attached a pcap where in there are RTP packets inside the TURN channel Data, but when i process this the library flags the master-protocol as STUN and APP-Protocol as ViberVoip. But lets say in cases, where there is RTP inside TURN channel OR there is RTP inside STUN(generally as part of DATA attribute, which we see for Skype and Teams calls) can we have a way where in we can flag the packet as the containing RTP data.
This information is not available.
I suppose that you are using the latest release or dev branch (because you didn't say otherwise) and the default configuration (for the same reason).
Keep in mind that nDPI only processes the first packets of the flow (usually in the 1-10 range). When the classification is complete and all expected metadata is extracted, nDPI doesn't process anymore the following packets of the session
Also, in some cases we see that even though the 4-tuple is not matching, then also the library is able to identify the flow as some voip call. Just, wanted to understand how does the processing takes place here, is it based on flow OR the library records something like IP and Port and then tries to check in flows??
nDPI uses a lot of different techniques to identify the traffic (payload inspection, IP address, ports, TLS certificates, flows correlation, statistical analysis,...) . If you are curious about Whatsapp calls, you might likely take a look at stun.c
I have attached a pcap where in there are RTP packets inside the TURN channel Data, but when i process this the library flags the master-protocol as STUN and APP-Protocol as ViberVoip. But lets say in cases, where there is RTP inside TURN channel OR there is RTP inside STUN(generally as part of DATA attribute, which we see for Skype and Teams calls) can we have a way where in we can flag the packet as the containing RTP data. i mean any attribute i can access which tells me this?....I have attached both viber and skype pcaps.
skype_call.zip
Also, in the viber pcap we can see that flow assigned as STUN and after than same flow is assigned as DTLS. Any reason for this?...
Also, in some cases we see that even though the 4-tuple is not matching, then also the library is able to identify the flow as some voip call. Just, wanted to understand how does the processing takes place here, is it based on flow OR the library records something like IP and Port and then tries to check in flows??... Example is below
Please help in clarifying the above two scenarios.
The text was updated successfully, but these errors were encountered: