Вот даже вру
16 это обычный bye
31 это 480

Тем не менее.
У sip много событий из тех что есть в TФоП просто нет.
Так что с совой и глобусом все актуально

А в астериске 603 отвечает плечо которое делало вызов. Так как для него причина - не 480 а просто отказ плеча b отвечать

Хотите конкретный маппинг- убирайте b2b и ставьте proxy

Происходит так с астериском вообще потому что плечо А астериска не знает о том какие действия будет производить плечо B по отношению к выхожу. Мб у вас там перебор операторов. Какой тогда ответ передавать? Последний? Предпоследний?
А может вы там внутренние какие то процедуры делаете после того как плечо B умрет и проиграет сообщение. Или сами в dialplan возьмете трубку.

Поэтому поведение астериска с 603 ответом- вполне логично

я уже писал 480 приходил и с 16 и с 31, да по стандарту 16 передается при завершении в ТФоП

603 передавало плечо, которое как раз вызов принимало, т.е. от октелл приходил запрос, далее астериск его передавал в шлюз оператора ТФоП, и при получении 480 от оператора отвечал 603 в плече к октелл

По отношению к астеиску от октела как раз входящее плечо. Я пишу как раз с этой точки зрения. Специально расставил же где плечо А а где B

Все правильно астериск передаёт на летел
Читайте что я написал выше

читаю конечно, но вы же только что говорили что 16 и 31 интерпретируются одинаково. А насчет совы и глобуса - если подключение идет к PSTN то поля формируются по правилам отображения событий в  значения полей SIP ISUP или DSS1 например, что я и хотел сказать

Я поправился выше ведь
При чем вы даже ответили на этот пост

А говорите что чиаете

Я говорю о том что вы ругайтесь на мапппинг хотя проблема не в нем.

нет, не ругаюсь, на форуме разработчикам задавали такой же вопрос, ответ был что все правильно. Вопрос в другом, зафиксировать со стороны оператора при каких причинах формируются 16 и 31 в ответе 480, но думаю это может зависеть от стека в конкретном шлюзе оператора.

Дело не в сэке. Дело в том что вы вместо шлюза или прокси ставите b2b а потом удивляетесь - чего это он как b2b работает

а где ставить шлюз или прокси вместо октелл астериск или SIP-PSTN GW. Вопрос изначально был про 16 и 31 в ответе 480, рад буду если ответите

Так я вам ответил. Тут нет трансляции. Плечо B получает ответ 480. На этом работа плеча B  заканчивается. Дальше работает плечо А.
Ему не очень важно что ответило плечо B.
У него свой канал. Свои задачи

с мэппингом астериска разобрались, тут вопросов нет, можно поменять cause и нет проблем, я же уже писал, вопрос в отличиях 16 и 31 со стороны оператора, вот и все, астериск не при чем. Я пытался разобраться какое состояние вызова/абонента ТФоП вызывает передачу 16 или 31

Ну есл  опять обратиться к  rfc то нет соотношения 480 с 16 кодом. Это просто оператор неправильно cause маппит судя по всему.

ну да, в ITU тоже указывается 16  при завершении, но  учитывая что оператор мобильной связи, то могут быть варианты с состоянием абонента, скажем не в сети, или ошибочный номер и т.д.

Но они же не могут отдавать "дозвонился" с 480.
Единственный вариант я предполагаю что оператору от мобильной сети приходит cancel и его гейт по SIP говорит 480. И сует 16 код от cancel. То это все равно неверный маппинг на операторе