там коммент?

да

все переменные устанавливаются на channel. так что они останутся всегда

11-13 что будет вместо log

единственно что в данном случае вы не сможете их в condition запихать.
потому что сначала идет роутинг, потом выполнение действий

отлично не хотелось это дублировать

только нужно быть уверенным что звонок попал в нужный кондишн

правильно понял что они в condition уже не будут? Всё что с 3 по 7 строчку для каждой очереди было, сейчас потребовалось привязку ко времени сделать чтобы раскидывать по очередями. Или проще будет сделать extension со временем и transfer отправлять на нужный extension со своей очередью?

как понимаю реализовать по разному можно

Здравствуйте, подскажите пожалуйста, можно как то на фрисвиче поднять dtls-srtp + sip-udp, если до то как)
Задача: есть ws шлюз, есть медиасервер собственно fresswitch, сходу завести схему не удалось, гуглёж в лоб тоже не дал результата, может статейки есть какие то толковые?

Самое простое - посмотрите kazoo2600 исходники
у них как раз так и сделано
в internal profile выставлен dtls-srtp
все работает

Коллеги, подскажете
Абонент А ——FS(bypass) —> Абонент Б
FS(bypass) —> Абонент С
абонент Б дает отбой , в диалплане у меня стоит
<action application="set" data="bypass_media=true" inline="true"/>
<action application="set" data="hangup_after_bridge=true" inline="true"/>
<action application="set" data="failure_causes=USER_BUSY,NO_ANSWER" inline="true"/>
<action application="set" data="continue_on_fail=true" inline="true"/>
<action application="bridge" data="{originate_timeout=15}sofia/gateway/my_gw/111111111111"/>
<action application="bridge" data="{originate_timeout=15}sofia/gateway/my_gw/1222222222"/>
то есть по соответствующим причинам отбоя я буду звонить на другого абонента (CallForward)

И вот что происходит при звонке на Б  сторона Б присылает 183  с SDP которые пересылаются А и идут от Б гудки, которые слышны. Когда происходит USER BUSY   мы начинаем вызывать абонента C  оттуда тоже приходит 183 с SDP  , который стороне А не посылаются, потому что фрисвич 183 от абонента C  не посылает в А
происходит ответ на стороне С ,  отправляется 200ок c SDP  фрисвич их пересылает А.  Звука нет.
Что я делаю не так, что не происходит ресогласование медии

давольно просто и банально всё оказалось, нужно было просто внимательнее смотреть в документацию. media_webrtc=true в dialstring и всё залетало

вероятно две трети всех возникающих "неразрешимых" вопросов именно так и отпадают)

SIP/2.0 480 Temporarily Unavailable
  Via: SIP/2.0/UDP .........
  From: <tel:+7495.........>;tag=tjyr66QmX0D0D
  To: <sip:+79.......@ip.....;user=phone>;tag=UUQH818Qt93jS
  Call-ID: d6a61f23-8339-1239-7ebb-005056a965fd
  CSeq: 26482717 INVITE
  User-Agent: Freeswitch
  Accept: application/sdp
  Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,REGISTER,REFER,NOTIFY
  Supported: timer,path,replaces
  Allow-Events: talk,hold,conference,refer
  Reason: Q.850;cause=16;text="NORMAL_CLEARING"
  Content-Length: 0
 
Вопрос как во фрисвиче после прочитать заголовок Reason ?
Reason: Q.850;cause=16;text="NORMAL_CLEARING"

оно?)

провайдер в тексте в Reason  направляет интересные причины, не стандартные , их и хотелось бы прочитать. То есть хочется прочесть содержимое заголовка

Стандартные причины, я периодически пролистываю и приблизительно представляю о чем они

К примеру провайдер может направить  там что нибудь типа user not registred