Version

Introduced in Asterisk 1.4

Description

directrtpsetup=yes is similar to directmedia=, except the audio is redirected in the initial INVITEs rather than reinviting the media a
few RTP packets in. Note: canreinvite= was renamed to directmedia= in Asterisk 1.6.2 to more accurately describe what this setting does.

Q: Is there a way to force asterisk to take care only of sip signaling without forcing it to take care of rtp traffic?

A:: Yes. The canonical way is to enable "canreinvite=yes" on both SIP peers (incoming and outgoing legs), which will cause Asterisk to send a new INVITE within the dialog that has updated SDP information corresponding to both endpoints.

The more interesting option is newer — "directrtpsetup=yes" in sip.conf. This will cause Asterisk to behave more like a proxy does with respect to media and simply pass the SDP payloads as received to both endpoints without pivoting the media stream toward itself at any time, unless explicitly forced to do so (i.e. generating music on hold or IVR messages).

Both approaches come with the caveat that the endpoints must be able to address each other directly, so it can't be that one endpoint is behind NAT on a private network that only Asterisk can see and the other endpoint cannot. But if that's taken care of, or you have a far-end NAT traversal solution in place to go with it, then you can do media release on Asterisk.

Troubleshooting

• Use the CLI command RTP DEBUG IP <Device IP Address>

See also

• Asterisk sip canreinvite
• Asterisk config sip.conf