Mikrotik devices have a build-in tool called Packet sniffer, which does exactly what I need but what if I had these captures on a remote PC ? RTP / SIP Debugging with Wiresharkįollowing the same process as last time around, we can now start taking a look at the full SIP flow including our captured RTP payload as well as using the Wireshark player tool.Today, for troubleshooting purposes, I needed to capture traffic from a Mikrotik wireless access point that I have. There are numerous options here, so we will cover that in more detail in a later tutorial. To do this, you will need to choose those peers which can use re-invites and then to add the appropriate code to the corresponding contexts within the sip.conf file. How is this done?Ī good idea is to disable re-invites as outlined above under the context and then allow re-invites on a peer by peer basis. However, what if you want some RTP to be routed across your server but want to allow re-invites for other calls? An example scenario could be to record calls in a call center, but allow re-invites for all internal calls in the back office. To change the re-invite behaviour across your entire system, you will need to enter the following line of code under the context, as follows: canreinvite=noĪs mentioned above, this well prevent re-invited universally across your Asterisk system, therefore routing all your RTP traffic across the server, which is what we need for our debugging purposes. First, you need to be logged into your Asterisk server as root and then open the sip.conf file. Thankfully, changing the Asterisk’s default behaviour is this regard is fairly straight forward. However, what if you need to route the traffic over the server in order to record calls or to debug your RTP payload in Wireshark? What then? This has some advantages in that this behaviour lessens the traffic being routed over the Asterisk phone system server. The default behaviour of an Asterisk system is to automatically allow re-invites.
0 kommentar(er)
