Is there a way to divert the RTP, and remove the server from the call “loop” once a call is established to minimize server load?
Assuming I have a “A” SIP user, “B” FreePBX server and a trunk to a “C” termination provider. In a call initiated by user A, the signaling goes through the sever, to the C termination provider. The way I understand the call process, once a call is initiate, the server can/should step-out and the RTP should run directly between the A SIP user and C provider (until hangup).
The situation we see today is that the server is involved with RTP sessions, during the whole conversation (using Hummer TCP dump).
- What trunk settings are needed to remove the RTP streaming through the server?
- Any other server global settings should be modified?
- The point is to minimize server load, would it work?
thanks ahead for all input,
You need to understand the architecture of Asterisk to decide if direct RTP stream is right for your environment. Network topology plays a big role as it is not NAT friendly.
In Asterisk SIP trunks the reinvite behavior is configurable on a peer to peer or global bases.
So the RTP is negotiable on a trunk basis, or global settings.
- What value on the trunk settings affect the trunk’s RTP load (reinvite).
- Where are the global settings?
- are there any benefits/advantages in routing the RTP via the trunk?
Pl.explain in detail,how to configure peer to peer. or Global bases in Sip Trunks
During my search on the issue of RTP diversion I have come across this article:
I believe it clearly explain all issue and related subjects.
have fun on testing
I got a trunk with directrtpsetup=yes.
How do I know if this is working? I checked the logs with verbose 10, debug 10, sip debug on, etc… and it looks ok but how do I know for sure that directmedia is working? What am I looking for in the log? Thanks.
The RTP debug shows the following lines:
Sent RTP packet to xx.xx…:50458 (type 00, seq 057812, ts 3282009200, len 000160)
Got RTP packet from yy.yy…:17888 (type 00, seq 036609, ts 3282009365, len 000160)
where xx.xx… is the originating IP
and yy.yy… is the destination IP
Looks like it’s working as intended since the Asterisk server IP address is not mentioned anywhere in the RTP debug lines. Can anyone confirm this?