A
Вангую что отключение оффлоада заставило ядро считать чексуммы и таким образом в pcap стали попадать верные значения для отсылаемых пакетов
Size: a a a
2021 April 16
A
Это ровно ни на что не повлияло кроме того что в трейсе видны красивые чексуммы
АФ
разве в расчет ядро гипервизора брать не надо который делает перетосовку
A
У меня есть много разных гипервизоров и ни один не перетасовывает пакетов в рамках L4 потока. Это происходит потому что сетевой стек разработан так чтобы ничего не перетасовывалось
ГБ
Спасибо большое!
E
Всем здорова.
Помогите разобраться, я позвонил с юзера 1000 на юзера 1001, дал отбой с 1000. В итоге получил 2 cdr лога (aleg и bleg). В cdr aleg значение
https://freeswitch.org/confluence/display/FREESWITCH/sip_hangup_disposition
Помогите разобраться, я позвонил с юзера 1000 на юзера 1001, дал отбой с 1000. В итоге получил 2 cdr лога (aleg и bleg). В cdr aleg значение
sip_hangup_disposition=recv_bye. Но так как aleg это звонящий юзер и отбой дал он то как я понимаю значение должно быть send_bye. Кто может объяснить почему так происходит? Или это баг какой то?https://freeswitch.org/confluence/display/FREESWITCH/sip_hangup_disposition
GV
Все правильно, со стороны А получен BYE -> recv_bye
P
Это трактовка с точки зрения самого FS.
E
Точно! Спасибо
АФ
если внимательно присмотреть в env можно увидеть что в самом начале есть direction которая грубо говоря образует что есть такое aleg/bleg
исходя из этого значения + sip_hangup_disposition делается грамотное заключение по отношению recv_bye/send_bye
у вас уже образуются 2 cdr на одном звонке которое облегчит понимание aleg/bleg
исходя из этого значения + sip_hangup_disposition делается грамотное заключение по отношению recv_bye/send_bye
у вас уже образуются 2 cdr на одном звонке которое облегчит понимание aleg/bleg
KV
originate user/XXXXX &bridge(user/yyyy) - даст обе ноги outboundKV
Какая из них тут А, какая Б ?
KV
А и Б - это очень условное понятие.
АФ
забавно, осталось еще конференцию приплести
или еще лучше скрипт начинает собирать собирать в конференцию, тут вообще можно сказать все одноногое
или еще лучше скрипт начинает собирать собирать в конференцию, тут вообще можно сказать все одноногое
АФ
на одной ноге будет getHeader("is_outbound"), на другой getHeader("is_inbound"), set direction=тра...та..та вообще отношения не имеет к этому
АФ
занимательный скрин для начинающих который показывает связи uuid звонка по отношению aleg/bleg
но не вижу взаимосвязи между направлениями in/out, может просто что-то не доглядел
но не вижу взаимосвязи между направлениями in/out, может просто что-то не доглядел
АХ
Direction показывает направление канала по отношению к фрисвичу.
KV
На самом деле,
send_XXX или recv_XXX не зависит от того, в каком направлении изначально был INVITE. Он говорит только о том, в кком направлении было завершающее действие. send - это FS что-то послал, recv - это FS что-то принял от внешней точки. А А или Б это была нога, inbound или outbound совсем не важно.KV
А конкретно в этом случае, совершенно логично, что в связанных плечах если кто-то "пришлёт" BYE, то другая сторона его "получит".