I want to set 2 extensions to make a connection by Direct Media RTP Transport, how can I set the DirectMedia Transport with the extensions??? I find that station A called station B, the RTP always through the Asterisk, but I want some extension transport the RTP directly (also video signal).
Direct media for video is not supported as of this time.
For audio, it would be directmedia=yes or nonat (canreinvite=yes on much older versions)
There’s also directrtpsetup=yes if you want even the initial media to go through the PBX.
Note that this will break in NAT setups, sometimes even with the nonat option. This means that having nat set to anything but “no” will tell asterisk to ignore the directmedia setting.
nat= doesn’t control whether or not the peer is treated as requiring NAT. That is based on localnets (for chan_sip).
nat= applies variious workarounds that a useful when the peer doesn’t fully understand the affects of NAT.
I suppose it is possible that nat=comedia could conflict with directmedia, as it does require initial media packets to actually pass through Asterisk, but it will do so even if there is no actual network address translation.
Also, to the best of my knowledge, directrtpsetup has never been officially supported.
Thanks for all your answers, I will try all the provided solutions.
Well before you do that can you please clarify one thing? Are you using Chan_SIP or Chan_PJSIP? It’s actually a very important question as while the settings are the same name (in most part) between the drivers, they are not the same settings. PJSIP uses snake case so while in Chan_SIP it is directmedia=no in Chan_PJSIP it is direct_media=no and PJSIP is also NAT aware so there is no nat= setting in PJSIP. You’ll want force_rport=yes and rewrite_contact=yes.
Asking if it’s Chan_SIP or Chan_PJSIP should always be the first clarification as using the wrong settings in Chan_PJSIP will stop the object (endpoint, aor, etc) from loading and could stop PJSIP from loading. Plus putting Chan_PJSIP settings in Chan_SIP will not work either, however, Chan_SIP will still load.
chan _pjsip is no more NAT aware than chan_sip in terms of nat=*. It simply breaks the sub-options of nat= into fully fledged options, so that nat=comedia becomes rtp_symmetric=yes and nat=force_rport becomes force_rport=yes. The common incantation of nat=force_rport, comedia is equivalent to specifying both options.
As I said before nat= is about workarounds for dysfunctional NAT environments; it doesn’t control whether or not translation happens.
This was my whole point. That 5+ years after Chan_PJSIP was introduced and Chan_SIP was marked deprecated with Digium stopping all development on it (just like IAX, Chan_SIP is 100% community supported now) the first response to all SIP issues is based on Chan_SIP logic/settings. That is no longer the case. There is more than one SIP driver in Asterisk now. You cannot assume that everything is just Chan_SIP.
Just to clarify, I am using SIP
Both chan_sip and chan_pjsip implement SIP.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.