error, как я уже писал ранее, действие Belonging domain и так известно.



Потому, что не указан сценарий вызова и участвующее оборудование c IP адресами.
Однако, помогу вытереть твои сопли, указав на Via: SIP/2.0/UDP 10.180.140.2:5060, т.е. вызов через эту сущность уже прошел.

Или требовался ответ вида "потому что искрател настроен так-то и так-то" ?

error, сходи, почитай RFC и TG.

По делу - 503 надо лечить со стороны встречного оборудования, или, как минимум, совместно с персоналом с той стороны.
99% она не имеет отношения ни к Belonging Domain, ни к Realm.
Возможно, кодеки (например, включить G.729), возможно, недонастроено оборудование на встречной АТС.

Желающие могут увидеть пример обмена с аутентификацией в TG 42 ed5, например, на стр. 37.

Там прекрасно видно, что домен из From (он же Belonging), содержимое Contact и содержимое realm - три разницы.

Конечно куда уж вам, с методом тыка-то.

На какую из так называемых "технологий регистрации" вы ссылаетесь, RFC, пункт ?

Какое отношение имеет аутентификация к отказу 503, относящемуся к "серверным" отказам ?
Напомню - аутентификация в приведенном трейсе прошла успешно, а ошибка аутентификации - это "клиентская" ошибка, 401.

Это не говоря о ереси о том, что провайдер обязательно ждет PCMU в SDP.

error, курите внимательно RFC 3261 и ссылки из него,
Belonging Domain/Realm имеют отношение к аутентификации, а не к тому, что Contact==From обязательно.
Также курите внимательно трейсы, в которых видно, что аутентификация с From<>Contact уже успешно прошла, т.е. Realm уже отработал.

Какая связь между различием Contact/From И ответом 503 (34 no channel/circuit) ?

Между прочим, в Contact тот же адрес, что в Via, небось прокси, или SBC.
Непонятно, почему (на основании какого RFC) вы считаете, что From и Contact  должны совпадать.

Вообще-то, в приведенном трейсе уже есть

m=audio 32612 RTP/AVP 8 4 97
a=sendrecv
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:30

а PCMU в общем-то ни к селу, ни к городу.

Так что это вопрос к провайдеру, что ему не нравится в SDP, какой кодек он мечтает видеть.

Так а в трейсах (tcpdump) смотрели, все отдается провайдеру нормально ?
Можете настройками добиться такого же трейса, как при регистрации звонилки, раз она у вас регистрируется ?

А зачем вы адрес SBC вообще куда-то вписываете ?
Ваша звонилка, по всей видимости, в качестве прокси для исходящих вызовов использует тот же прокси, что и для регистрации. Пропишите и на ОХЕ так же, вроде же в доке про варианты конфигурирования публичных SIP транков все варианты с примерами разрисованы.

А в звонилке вы при этом какой из адресов прописываете - Proxy, или SBC ?
Такой же и станции прописывайте.

Так это вопрос к удаленной стороне, почему они вам 403 выдают и каковы параметры регистрации.
Почему вы пытаетесь только у себя все накрутить, без соответствия параметрам удаленной стороны ?
Параметры вам выданы, регистрация на прокси проходит успешно ?

Где это видано, где это слыхано, форум решает, а Анна сдает!

Как вариант, могут быть разные таблицы соответствия таймслотов и channel Id с разных сторон.

Странно это, или нет, но это так.

ALU подсказал решение: на это, оказывается, влияет параметр
Calling name display (CNIP/I-CNAM) : 1 в Phone Feature COS.

Правда, работает не все, но имя вызываемого абонента отображается.