ааааааааааа то есть  по сути на время исполнения сеанса мне будет доступна переменная как локальная и внутри приложения к ней можно будет получить доступ как session:getVariable("var1") session:getVariable("var2"), dct ntgthm все теперь перечитал доку еще раз и дотумкал

Что быстро пришло в голову это пример вот такой и ему подобные
<action application="set" data="curl_timeout=10"/>
<action application="curl" data="http://www.google.com"/>
может быть заменено на

<action application="curl" data="%[curl_timeout=10]http://www.google.com"/>

Я правильно понимаю что это типа такого ?

наверное

На external нет ACL - нужно только правильно разрулить в public контексте, если ничего не менялось.
Прийти транк должен на порт 5080, опять таки если не менялся дефолт

Убедитесь что инвайты вам летят на порт 5080.
По дефолту будут слать на 5060. Поэтому ловите в другом профиле отлупы.

Добрый день,

Если после ответа проигрываю анонс и записывать звонок, то этот анонс для outbound channel не попадает в запись.

Делаю record_session c RECORD_STEREO и bridge.
И поигрываю анонс
<action application="export" data="nolocal:api_on_answer=uuid_broadcast ${uuid} anons.wav both"/>

В результате в записи в одном канале есть приветствие, а в другом нет.

Подскажите пожалуйста можно как-то добиться чтобы приветствие попало в запись для обоих каналов?

Миксуйте

Добрый день!
Гуру SIP протокола, подскажите плиз: за 100 trying должен ли обязательно идти 180/183 Ringing? И если его нет, то может ли вызывающий прислать ACK?

Silero TTS Released

Surprise! A quick pre-release of Silero Text-to-Speech models!

Speakers

10 voices (each available in 16 kHz and 8 kHz):

- 6 Russian voices;
- 1 English voice;
- 1 German voice, 1 Spanish voice, 1 French voice;

Why is this Different?

- One-line usage;
- A large library of voices;
- A fully end-to-end pipeline;
- Naturally sounding speech;
- No GPU or training required;
- Minimalism and lack of dependencies;
- Faster than real-time on one CPU thread (!!!);
- Support for 16kHz and 8kHz out of the box;

Links

- Try our TTS models here;
- Quick summary;
- Performance benchmarks;

Stay tuned for much more detailed PR releases and torch.hub release soon!

Суть проблемы такова:
Есть Cisco 2911 как voip шлюз
периодически на нее не проходят звонки
дампами собрал такую картину
нормальная последовательность звонка:
звоняший INVITE
Cisco 100, 180, 200
звонящий ACK

100/183 это provisional response.
ack подтверждает получение final response 2xx,3xx,4xx,5xx,6xx

А какую-то выдержку из RFC?

потому что я нашел, что ACK может и на invite быть

RFC3261:
  The ACK request for a non-2xx final response to this request would
  look like this:

то есть ack может быть и не на 2xx response

ну кроме 2хх, могут быть 3хх,4хх,5хх

и для них ack ведет себя не так как для 200

в одном случае hop-to-hop
в другом end-to-end

Ок, мой вопрос немного в другом, закончу мысль
Когда звонки перестают приниматься, последовательность такая:
звонящий INVITE
cisco 100 Trying
звонящий ACK
Cisco 403 forbidden

вопрос - правомерно ли такое поведение cisco?