Разработчики предоставили обратную связь:
В плече, которое ушло в SIP-транк, изначально был получен ответ SIP 183, затем абонент поднял трубку. После этого система отправила reINVITE, что согласовать кодеки после перехода с 183 Early-media на трафик от абонента. Система отправила INVITE без кодеков, и получила ответ 200 OK без кодеков.
На нашей стороне система считает, что ответ 200 OK без SDP на reINVITE без SDP это невалидная ситуация.
Если я правильно понимаю RFC 3261 пункт 14.2
A UAS providing an offer in a 2xx (because the INVITE did not contain
an offer) SHOULD construct the offer as if the UAS were making a
brand new call, subject to the constraints of sending an offer that
updates an existing session, as described in [13] in the case of SDP.
Specifically, this means that it SHOULD include as many media formats
and media types that the UA is willing to support. The UAS MUST
ensure that the session description overlaps with its previous
session description in media formats, transports, or other parameters
that require support from the peer.
то рекомендуется, чтобы сторона получившая reINVITE без SDP, ответила всеми кодеками, которая она поддерживает.
В данном случае, этих кодеков в ответе нет. Система считает, что кодеки не согласованы и не проключает трафик между плечами.
Проблема в том, что такое поведение РЕКОМЕНДУЕТСЯ, а не ТРЕБУЕТСЯ. Но наша система в этом месте требует кодеки.
