Доброго времени суток!
Кто-нибудь в курсе, чего не хватает в SETUP`е исходящего от Meridian`а соединения, если вызов обрабатывается через SPN, включающий SDRR ARRN коды?

DCH 12 UIPE_OMSG CC_SETUP_REQ REF 00006073 CH 18 8 TOD 0:00:29 CK 5311AF1B
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:351xxxxxxx NUM PLAN: E164 TON: NATL
CALLED #:2xxxxxx NUM PLAN: E164 TON: UNKNOWN

DCH 12 UIPE_IMSG CC_MORE_INFO_IND REF 00006073 CH 18 8 TOD 0:00:29 CK 5311AFDF

DCH 12 UIPE_IMSG CC_PROCEED_IND REF 00006073 CH 18 8 TOD 0:00:35 CK 5311D792

DCH 12 UIPE_IMSG CC_ALERT_IND REF 00006073 CH 18 8 TOD 0:00:35 CK 5311D916
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 12 UIPE_IMSG CC_SETUP_CONF REF 00006073 CH 18 8 TOD 0:00:39 CK 53120353
PROGRESS: TERMINATING END IS NOT ISDN

DCH 12 UIPE_OMSG CC_DISC_REQ REF 00006073 CH 18 8 TOD 0:00:55 CK 53127537
CAUSE: #16 - NORMAL CALL CLEARING

DCH 12 UIPE_IMSG CC_RELEASE_IND REF 00006073 CH 18 8 TOD 0:00:55 CK 531275A6

DCH 12 UIPE_OMSG CC_RELEASE_RESP REF 00006073 CH 18 8 TOD 0:00:55 CK 531275A7

В ответ на SETUP Meridian`а прилетает CC_MORE_INFO_IND (SETUP ACK) с M-200. Далее 4...8с бесполезного ожидания INFORMATION от Meridian`а. После чего М-200 успешно продолжает обработку вызова.
Жаба давит ждать эти 4...8с!

Вот сам SPN:

SPN 02
FLEN 8
ITOH YES
CLTP NONE
RLI 10
ARRN 679
ARLI 5
ARRN 723
ARLI 5
SDRR ARRN CODES = 2
ITEI NONE


Вызов, идет, кстати по RLI, а не по ARLI.

А если # нажать?

Помогает. Проверял на i2050, предварительно набрал 2xxxxxx#, затем занятие линии - все быстро. Только как подсунуть # абонентам в КОНЕЦ НАБОРА?

ИМХО со стороны Меридиана все нормально. Может на стороне м-200 что-то недопрописано, например длина номера.

ИМХО со стороны Меридиана все нормально. Может на стороне м-200 что-то недопрописано, например длина номера.
Техподдержка МТА именно посоветовала лечить этот эффект жестким прописыванием длины номера в таблице маршрутизации (типа 2******). Со стороны EWSD вылечилось (там тормозилась обработка входящих), со стороны Meridiana`а - нет.
Насчет "нормальности" ARRN: она меня и раньше напрягала. В SPN`е четко указан FLEN=8 и ITOH YES. Вправе ожидать, что в канал уйдет ровно 8 цифр. Но анализ отсева в биллинге, показывал, что абоненты, бренча кнопками, умудрялись впихнуть лишние цифры в канал (на маршрутах, включавших SDRR ARRN). Тогда я не стал искать принципиального решения, просто прописал длины набора по этим маршрутам в пребиллинге. Но вопрос вылез снова...

DCH 12 UIPE_OMSG CC_SETUP_REQ REF 00006073 CH 18 8 TOD 0:00:29 CK 5311AF1B

DCH 12 UIPE_IMSG CC_MORE_INFO_IND REF 00006073 CH 18 8 TOD 0:00:29 CK 5311AFDF

DCH 12 UIPE_IMSG CC_PROCEED_IND REF 00006073 CH 18 8 TOD 0:00:35 CK 5311D792


Причем тут способ маршрутизации на Меридиане? В 0:00:29 ушел сетап и тут же вместо PROCEED встречная сторона шлет MORE_INFO_IND и только в 0:00:35 присылает требуемый по идее сразу PROCEED. Вот ваши 6 секунд. Надо понять, что они хотят в MORE_INFO_IND, возможно со встречной стороны набор ожидается оверлапом. Хотя при правильно прописанных длинах на дальней стороне разницы не должно быть.

Причем тут способ маршрутизации на Меридиане? В 0:00:29 ушел сетап и тут же вместо PROCEED встречная сторона шлет MORE_INFO_IND и только в 0:00:35 присылает требуемый по идее сразу PROCEED. Вот ваши 6 секунд. Надо понять, что они хотят в MORE_INFO_IND, возможно со встречной стороны набор ожидается оверлапом. Хотя при правильно прописанных длинах на дальней стороне разницы не должно быть.
Убираешь из SPNа SDRR ARRN - и никаких лишних задержек. Т.е. PROCEED сразу и приходит. Об этих 6-ти сек речь сразу и шла. Опыты с длинами на дальней стороне (М-200) я уже проделал (по совету МТА). Не помогло.
Ветку я затевал в надежде уточнить особенности канального обмена при включенном SDRR ARRN.

Причем тут способ маршрутизации на Меридиане? В 0:00:29 ушел сетап и тут же вместо PROCEED встречная сторона шлет MORE_INFO_IND и только в 0:00:35 присылает требуемый по идее сразу PROCEED. Вот ваши 6 секунд. Надо понять, что они хотят в MORE_INFO_IND, возможно со встречной стороны набор ожидается оверлапом. Хотя при правильно прописанных длинах на дальней стороне разницы не должно быть.
Гы... Убрал оверлап. У меня было OVLS YES (зачем когда-то ставил, уже не вспомню). Все поехало как надо. Гран мерси Urri за подсказку.

Тема закрыта.

:)