вдруг кому интересно
в самом RFC 3311 прям в первом пункте, есть упоминание принципа метода update
"to update session parameters without impacting the dialog state itself."
т.е. метод будет обновлять сессию не влияя на само состояние диалога.
у нас же ещё как влияет, но не из-за изменения, а из-за не возможности, что-то изменить.
Но это только косвенно, т.к. идёт описание принципа работы метода. т.е. это не гарантия, что какая либо ошибка не влечёт разрыв сессии.
но наводит на мысль, что идея метода в том, что бы сессия не разъединялась, а не наоборот - ненавредить.
но что за UPDATE запрос шлёт Samsung?
в RFC 3311
пункт 5.1 Sending an UPDATE, говорится, что запрос UPDATE должен:
"The rules for inclusion of offers and answers in SIP messages as defined in Section 13.2.1 of RFC 3261 still apply."
т.е. запрос отправляется в соответствии с RFC 3261 и как описано в 13.2.1
где в свою очередь говорится:
"it is possible that both the INVITE and the ACK contain a body message"
т.е. UPDATE запрос (по сути не отличающийся особо от INVITE и AСK) должен иметь "body message"
у запроса от астериска видимо UPDATE по RFC 3311
есть поле "body message", а в нём "Session Description Protocol" т.е. SDP который упоминается в стандарте 3311
(собственно в INVITE так же сформировано body message")
а вот от Samsung'а такого нет. только Header.
так же в Header нет пункта "Content-Type: application/sdp"
что наводит на мысль, что этот ТА несёт какую то чушь (не передает контент), а точнее как будто бы Samsung пишет письмо, в котором тему указал, а вот в письме ничего не написал, и вложение не вложил.
еще в запросе UPDATE от самсунга есть "Allow-Events: talk,hold" (Allow-Events описан в rfc 3265)
чего нет в INVITE и UPDATE от астериска.
но это поле присутсвует во всех пакетах от самсунга, а вот от других пиров я его не вижу.
это ни о чём особом пока не говорит. только о том, что самсунг поддерживает 2 события talk и hold, видимо
это я попробовал сравнить запросы UPDATE от самсунга и от астериска
далее
астериск даёт на UPDATE от самсунга ответ 501
из документации RFC 3261
21.5.2 501 Not Implemented
такой ответ когда метод не распознан.
и тут же есть сноска, что если метод запрещен, то будет другое сообщение.
Note that a 405 (Method Not Allowed)
на астериске было canreinvite=no
т.е. по идее метод запрещен.
а у нас именно не распознан.
всё это наводит на мысль, что от Samsung'a приходит неправильный UPDATE. И астериск не знает, что с ним делать, ведь "body message" отсутсвует.
а в нём и протокол SDP в котором вся информация о изменениях.
и большой вопрос можно ли такой запрос вообще обработать (при работе по RFC 3311), и поможет ли обработка такого запроса изменить ситуацию.
например вручную подсунуть пакет 200 ОК. поможет ли это ситуации?
или дело во все не в ответе, а в дальнейших или же предшествующих алгоритмах, которые дают сбой, приводящий к разрыву сессии?
в общем пока такие мысли...