А
получив ответ 1xx на INVITE сессия может находиться в состоянии "без 200 и с любым состоянием RTP" любое количество времени. Нет там таймеров, которые это регулировали бы.
Size: a a a
2020 December 02
А
Вы про uas забыли. Он контролирует.
А
Почитайте про транзакции в сипе .
АХ
Нет, тут совершенно другая ситуация. Есть потенциальная возможность установления сессии между абонентами без фактического прихода ответа. Очень не хочется внезапно выяснить, что биллинг не увидел 200 ОК и поэтому разговор не посчитал.
А разве фс может сбриджевать каналы которые не в answer?
BB
UAS работает в соответствии с RFC (по крайней мере, должен). В RFC определен перечент причин, по которым UAS может посчитать сессию оборвавшейся. Все эти причины связаны с истчением определенного таймера. Вместо того, что б отправлять меня "почитать что-нибудь", если у Вас есть конкретное знание причины подобного поведения, вы это знание выскажите. Ну или это просто базар ни о чем. На картинке выше исчерпывающий перечень таймеров. Выберите, какой из них Вам больше нравится в качестве обоснования Вашего мнения.
BB
А разве фс может сбриджевать каналы которые не в answer?
по-моему, нет...
А
UAS работает в соответствии с RFC (по крайней мере, должен). В RFC определен перечент причин, по которым UAS может посчитать сессию оборвавшейся. Все эти причины связаны с истчением определенного таймера. Вместо того, что б отправлять меня "почитать что-нибудь", если у Вас есть конкретное знание причины подобного поведения, вы это знание выскажите. Ну или это просто базар ни о чем. На картинке выше исчерпывающий перечень таймеров. Выберите, какой из них Вам больше нравится в качестве обоснования Вашего мнения.
Я ещё в первом сообщении подробно все описал. ещё раз: сервер который пошлёт 200 и стартанёт таймер до получения ака и будет делать ретрансмиты а после разорвёт сессию.
BB
Я ещё в первом сообщении подробно все описал. ещё раз: сервер который пошлёт 200 и стартанёт таймер до получения ака и будет делать ретрансмиты а после разорвёт сессию.
Значит Вы пропустили, что никто не шлет 200.
А
У вас там ведомственная сеть и каждый использует самописный сип клиент?
А
Ну и тогда по времени дозвона будет отбой конечно.
BB
Ладно, это все лирика, есть конкретная проблема (непосредственно с указанной не связанная), мнение о которой тоже хотелось бы услышать в сообществе.
есть сервис "голосовая капча": при выходе на МН линию клиенту в pre_answer состоянии проигрывается три цифры, которые клиент должен передать dtmf-ом. Если цифры совпали, то клиент пропускается на МН линию, если нет - не пропускается.
схема работы такая: операторский свитч отправляет нам звонок на фрисвич, там делается пре-ансвер, выполняется капча. После этого фрисвич надо исключить из медиаобмена. Как РАБОТАЕТ на некоторых свичах (но, судя по всему, это нарушает RFC), но не работает со свичами Nokia:
1 делаем pre_answer
2 проигрываем цифры
3 слушаем inband-dtmf
4 устанавливаем bypass_media=true
5 делаем исходящий звонок при помощи bridge
профит. Но при этом нарушается RFC, на что сослались инженеры Nokia при разборе проблемы. А именно: сначала в 183 отправляется SDP-answer с одним значением
есть сервис "голосовая капча": при выходе на МН линию клиенту в pre_answer состоянии проигрывается три цифры, которые клиент должен передать dtmf-ом. Если цифры совпали, то клиент пропускается на МН линию, если нет - не пропускается.
схема работы такая: операторский свитч отправляет нам звонок на фрисвич, там делается пре-ансвер, выполняется капча. После этого фрисвич надо исключить из медиаобмена. Как РАБОТАЕТ на некоторых свичах (но, судя по всему, это нарушает RFC), но не работает со свичами Nokia:
1 делаем pre_answer
2 проигрываем цифры
3 слушаем inband-dtmf
4 устанавливаем bypass_media=true
5 делаем исходящий звонок при помощи bridge
профит. Но при этом нарушается RFC, на что сослались инженеры Nokia при разборе проблемы. А именно: сначала в 183 отправляется SDP-answer с одним значением
c=, а потом в 200 OK отправляется еще один SDP-answer, в котором в SDP атрибуте c= указан другой IP адрес и другие порты для подключения. Я когда теоретически рассматривал эту конструкцию, вообще говоря, сомневался, что фрисвич так умеет. Но он умеет. А Nokia - нет. Они предлагают использовать UPDATE для обновления состояния SDP offer/answer после первого согласования. Соответственно, вопрос: а сабж умеет UPDATE? как?A
> когда теоретически рассматривал эту конструкцию, вообще говоря, сомневался, что фрисвич так умеет. Но он умеет. А Nokia - нет.
и правильно делают что не умеют, если в 180/183 был отослан SDP то в 200OK должен отсылаться ровно этот же SDP
и правильно делают что не умеют, если в 180/183 был отослан SDP то в 200OK должен отсылаться ровно этот же SDP
BB
> когда теоретически рассматривал эту конструкцию, вообще говоря, сомневался, что фрисвич так умеет. Но он умеет. А Nokia - нет.
и правильно делают что не умеют, если в 180/183 был отослан SDP то в 200OK должен отсылаться ровно этот же SDP
и правильно делают что не умеют, если в 180/183 был отослан SDP то в 200OK должен отсылаться ровно этот же SDP
Да, я понимаю и согласен. Вот сейчас надо сделать ровно. Это либо 200ОК + re-INVITE, либо UPDATE. По внутренним причинам делать re-INVITE сложнее. Умеет ли фрисвич UPDATE?
I
Да, я понимаю и согласен. Вот сейчас надо сделать ровно. Это либо 200ОК + re-INVITE, либо UPDATE. По внутренним причинам делать re-INVITE сложнее. Умеет ли фрисвич UPDATE?
а REFER не пойдет?
I
проще всего будет сделать
BB
REFER ломает биллинг :( пробовали
BB
исключиться надо только из медиа-обмена, сигналку надо оставить у себя
I
REFER ломает биллинг :( пробовали
re-invite по той же причине не получится?
I
единственное где я видел генерацию UPDATE в фс - обновление caller_id_number, а вот чтоб SDP переформировать - только костыль с правкой switch_r_sdp