With chan_sip is it possible to take Asterisk out of the media path at the dialplan level rather than at the SIP peer level? For example a dialplan equivalent to setting the directmedia/directrtpsetup values - or indeed can you set those values dynamically in the dialplan on a per-call basis before the Dial application is called (or as part of the application call)? If it helps, no NATs are involved and my Dial command uses the g, i, b and U flags.
On a related but separate note, if I set both of the following in the [general] context in sip.conf:
Firstly, chan_sip should be considered dead. However, I think the only control you have is the side effect resulting from using dial options that are incompatible with direct media.
Thank you for your response - in answer to your question about what problem we’re trying to solve, currently we have directmedia set to no and therefore Asterisk is in the audio path for all calls. All our Asterisk servers are based in the UK, however we’ve now been asked if we can route some calls that would both originate and terminate in the US, with us effectively acting as a transit provider. To avoid the latency caused by the RTP routing from the US to the UK and back we could set up an RTP proxy in the US, however we would then need to take Asterisk out of the audio path for those particular calls (although it would still be in the signalling path). So basically I’m looking for a way for us to have Asterisk in the audio path by default (so that the rest of the calls work as before) and then make an exception for these US calls. From what you’ve said, am I limited to one of the following options?
Set directmedia to yes in the [general] context and set a dial option incompatible with direct media for the non-US calls.
Set directmedia to no in the [general] context and then set it to yes in the SIP peers corresponding to the US calls.
In the [general] context, set directmedia to no and set multiple directmediapermit lines corresponding to the IP ranges that the US calls would be originating from.
Or would some of those not work? (2) and (3) could be problematic, in that they would presumably require the US calls to be separated from all the other calls by IP/peer, which may not be a viable option, so (1) sounds more suitable, but which dial options would be incompatible with directmedia and would they be reliable in the sense that if they were set then would that mean that Asterisk would definitely be in the audio path, i.e. we wouldn’t end up in a situation where some of our non-US calls no longer had their audio anchored in Asterisk for some reason?
Finally, given the use case I’ve described, should directrtpsetup be set to yes for the US calls as well, and if so then would it just be a case of modifying the 3 options above so that the directrtpsetup setting matches that of directmedia in each case?
Sorry one more thing - regarding (1), as well as choosing a dial option that is incompatible with direct media it would also need “do nothing” in the sense of not changing how anything currently works, so which dial options would fit the bill on that front? Presumably setting t, T, h, H, w or W would allow the possibility of the corresponding DTMF sequence being inadvertently activated, or is there a way of somehow making that impossible by e.g. leaving the value blank in features.conf? Could you use L to do it by using multiple arguments and setting them to be impossibly high so that they are never reached? Or are there any other dial options that could be used?