Меню

Настройка cisco caller id



Настройка cisco caller id

Автор: Сгибнев Михаил ред. Костяной Максим

Технология Cisco CME была разработана для того, чтобы облегчить развертывание систем VoIP в малых офисах и филиалах больших компаний.

В данной статье мы рассмотрим вариант организации голосовой сявязи маленького офиса на базе Cisco 2801, IP Phone 7912 и IP Phone 2960G. При этом соединение с ТФОП осуществляется через 2FXO, хотя наиболее правильным в такой ситуации будет шлюзование через провайдера IP телефонии (к сожалению, возможности моего стенда не позволяли опробовать этот вариант).

Нам будут необходимы следущие файлы:

  • c2801-spservicesk9-mz.124-8.bin IOS с поддержкой CME
  • cme-124-9T.zip Файлы CME 4.0 для IOS 12.4(9)T
  • cme-gui-4.0.0.1.tar Web-интерфейс CME, польза довольно сомнительна.
  • ringtone.tar дополнительные рингтоны для телефонов

Взять их можно на официальном сайте http://www.cisco.com/cgi-bin/tablebuild.pl/ip-iostsp но вас попросят авторизоваться. Но если есть желание и настойчивость, то все вопросы можно решить.

Итак, минимально необходимым для работы CME является: Где файлы P00307020200.xxx являются прошивкой для IP Phone 7960G, а music-on-hold.au является рингтоном, который слышит абонент, при переводе линии на Hold.

Настройка маршрутизатора заключается в нескольких простых шагах:

Настройка TFTP, NTP и DHCP сервера: Стоит отметить, что если в сети уже присутствует DHCP сервер, необходимо настроить его на отдачу опций 150 или 66 (в DHCP Win2k, Win2003 присутствует только 66 опция), но в принципе ничто не мешает поставить шлюзом по умолчанию ваш прокси и сделать нормальный пул на cisco.

Приступаем к самому интересному, настройка службы telephony-service:

  • Указываем имя прошивки для IP Phone 7960
  • Задаем максимальное количество IP Phone, оно зависит от модели маршрутизатора и для 2801 составляет 30 штук.
  • Задаем максимальное количество номеров, присваиваемых IP Phone и обычным телефонам, подключенным с помощью ATA 186/ATA 188.
  • Указываем адрес голосового шлюза. Впрочем, это мы и есть.
  • Указываем таймаут звонка.
  • Системное сообщение, отображаемое на телефоне.
  • Задаем локаль. При этом следует учесть такую особенность — 7912 локализованы значительно лучше 7960. Если будете использовать 7941/7961 локаль лучше оставить Eng.
  • Формат времени и даты. Рекомендуется наличие NTP сервера, если вы хотите, чтобы корректно указывалось время звонков и время/дата на самом телефоне.
  • create cnf-files — Эта команда создает XML файлы конфигурации IP Phone, ее формат.
  • Задаем максимальное количество одновременных конференций.
  • Music on Hold, здесь, думаю, все ясно.
  • Задаем возможность перенаправления звонков/

При желании, можно составить телефонную книгу, которая будет доступна, например, для IP Phone 7912 «Каталоги — Службы каталогов — Локальный каталог». Указываем выход в ТФОП через FXO (в данном случае, в ТФОП пойдут все номера, начинающиеся на 9): Создаем образцово-показательный телефон 7960, с двумя линиями, номером 8888, переводом звонков при неответе и занятости на номер 8887. Задаем для этого телефона два номера быстрого набора (автоматически они прикрепятся к третьей и четвертым кнопкам) и вешаем входящие линии на первую и вторую кнопки соответственно. С телефоном 7912 все аналогично просто: Теперь привяжем один из телефоном прямым транком ко второму порту FXO: Хочу указать на то, что в этом случае на IP Phone накладывается довольно много ограничений, основными из которых являются:

  • ephone-dn, на который повешен транк, не может быть сконфигурирован на call forward, busy, or no answer. Хотя по моему личному опыту, эти функции на ephone-dn свободно прикрепляются и, по крайней мере, no answer, нормально отрабатывает, переводя звонок на другой телефон. Опять таки же, это может быть просто недоработкой программистов Cisco.
  • Не определяется номер звонящего. Отображается только тэг, приписанный к транку.
  • Транк FXO не поддерживает клавиши CFwdAll, Transfer, Pickup, GPickUp, Park, CallBack и NewCall.
  • Транк FXO не может инициировать конференцию.
  • Транк FXO не поддерживает перевод звонков. Однако, можно связать инициатора звонка и IP Phone в конференцию, нажав Hold. Инициатор конференции неспособен участвовать в конференции, но может переводить запросы на другие линии.

Разберем возможность перехвата звонков. Заодно рассмотрим понятие группыперехватв (Call-Pickup Groups). Назначим нашей тестовой группе номер 33 и приведем конфишурацию для телефонов с номерами 8000 и 8001. При звонящем телефоне 8000 перехватить звонок можно следующим образом:

  • Любой пользователь, не входящий в группу, нажимает клавишу PickUP(Перехват), набирает 8000 и перехватывает звонок
  • Пользователь, входящий в группу (8001), нажимает клавишу GPickUP(Групповой перехват), набирает * и перехватывает звонок
  • Любой пользователь, не входящий в группу, нажимает клавишу GPickUP(Групповой перехват), набирает 33 и перехватывает звонок
  • Пользователь, входящий в группу (8001), нажимает клавишу PickUP(Перехват) и перехватывает звонок

Последней фичей, рассмотренной в данной статье, будет Overlaid Ephone-dns.

Данная функция дает возможность совместного использования одной ephone-dn между несколькими телефонами. Эта функция может использоваться для приема входящих звонков и последующего их перенаправления. До 25 ephone-dns могут быть назначены на единственную телефонную кнопку.

Overlaid ephone-dns может использовать ephone-dn как с одним номером, так и с несколькими номерами. Порядок, в котором ephone-dn используются для входящих звонков определяется параметром preference. Например, с ephone-dn 1 до ephone-dn 4 имеют один и тот же номер 8500, и три телефона конфигурированы с командой button 1o1,2,3,4. В этом случае, звонок раздастся на телефоне с самым высоким preference, а номер звонящего отобразится на все телефонах. Второй звонок (если на первом телефоне все еще продолжается разговор и в его конфигурации есть команда no huntstop) поступит на телефон с текущим самым высоким preference. Теперь займемся украшательством.Закачаем на маршрутизатор файл ringtone.tar и распакуем его: В результате работы этой команды вы получите дополнительные рингтоны, воспользоваться которыми сможете, отредактировав файл RingList.xml и дав возможность получить к нему доступ по tftp. После этого через меню настроек можно выбрать более подходящий рингтон.

Читайте также:  Настройка и проверка apache

Подводя итоги хотел бы отметить, что технология Cisco Call Manager Express обладает достаточно широкими возможностями, которые сложно описать в вводной статье начального уровня, такими как голосовая почта и интеграция с поставщиками услуг IP-телефонии. Надеюсь, что данная статья подтолкнет читателя к более детальному изучению данной технологии.

Литература:

>

Обсуждение [ RSS ]
1.1 , swa_exp ( ? ), 18:03, 06/12/2006 [ответить] + / –
>Стоит отметить, что если в сети уже >присутствует DHCP сервер, необходимо настроить >его на отдачу опций 150 или 66 (в DHCP Win2k, >Win2003 присутствует только 66 опция).

Коллега, стоит отметить, что в вышеперечисленных системах, все таки есть возможность настроить 150 опцию!

1.2 , Денис ( ?? ), 15:34, 28/08/2007 [ответить] + / –
при настройке VoIP в связках Cisco IP Phone 7960 с 2811 и с 3745 получил следующее: телефон регистрируется на роутере,
получает все передаваемые файлы (прошивки, рингтоны, списки
рингтонов), но при этом на аппарат не поступает dial tone.
Так же на обоих роутерах нет возможности оперировать с возникающим голосовым портом 50/0/1.

Кто-нибудь сталкивался с подобным?

sho run | be epho
telephony-service
load 7960-7940 P0030702T023
max-ephones 2
max-dn 18
ip source-address 172.16.47.114 port 2000
timeouts ringing 60
create cnf-files version-stamp 7960 Aug 28 2007 14:54:34
max-conferences 8
call-forward pattern .T
time-format 24
date-format dd-mm-yy
transfer-system full-consult
transfer-pattern .T
!
ephone-dn 1
number 56
label Test_IP_Phone
preference 1
no huntstop
!
ephone 1
mac-address 0011.2014.88D5
type 7960

Источник

Caller ID

Для корректной работы Caller ID (АОН) необходимо чтобы оба устройства (SIP-адаптер и подключенный к нему телефонный аппарат или приставка-определитель) поддерживали один и тот же стандарт. Аппарат, купленный в России или в Европе, скорее всего, умеет работать с CLIP FSK, а значит надо сообразно настроить SIP-адаптер.

После правильной настройки на аппарате или приставке-определителе при поступлении входящего вызова может отображаться цифровой SIP ID, а также имя абонента, как оно прописано на вызывающей стороне.

При поступлении вызовов с телефонов доступа и «прямых» номеров, как правило, отображается реальный телефонный номер (АОН) звонящего абонента телефонной сети.

В SIP-адаптерах Linksys необходимо сделать настройки на странице Regional:

  • для работы с европейским телефонным аппаратом — Caller ID Method: ETSI FSK, Ring Waveform: Sinusoid; Ring Frequency: 25
  • при использовании американских аппаратов — Caller ID Method: Bellcore; Ring Voltage: 90; Ring Waveform: Trapezoid; Ring Frequency: 20

В современных моделях Linksys (и начиная с версии прошивки 5.2) в настройках есть параметр Caller ID Header, отвечающий за то, откуда будет браться информация Caller Id; возможные значения:
PAID-RPID-FROM, P-ASSERTED-IDENTITY, REMOTE-PARTY-ID, FROM header, PAID-RPID-FROM (используется по умолчанию). Рекомендованное значение — «FROM header».

В предыдущих моделях и прошивках Linksys используется параметр SIP Remote-Party-ID:

  • «yes» — информация будет взята из одноименного заголовка, при его отсутствии — из «P-Asserted-Identity», а при отсутствии и его — из «From»
  • «no» — информация будет взята из заголовка «P-Asserted-Identity», а при его отсутствии — из «From»

Для Cisco ATA параметр CallerIDMethod по умолчанию имеет значение 0x00019E60, что соответствует американскому стандарту Bellcore, максимум 12 цифр в номере и 15 символов в имени.

Возможная настройка для Европы — 0x00019E7E (стандарт ETSI, информация передается после первого звонка, максимум 15 цифр в номере и максимум 15 символов в имени).

В некоторых моделях D-Link, например в DVG-5004S, в настройках есть параметр SIP Caller ID Obtaining, отвечающий за то, откуда будет браться информация Caller Id; возможные значения: Remote-Party-Id Display Name, Remote-Party-Id User Name, From-Header Display Name, From-Header User Name (рекомендуется).

В аппаратах Gigaset нет соответствующих настроек и действует следующий алгоритм:

  • при наличии в сигнализации заголовка «P-Asserted-Identity:» будет показано его содержимое
  • иначе будет отображена информация из заголовка «From:»

Подробнее об использовании заголовков SIP:

Remote-Party-Id Display Name: Заголовок «Remote-Party-ID:» → содержимое перед [ Статья

  • Обсуждение
  • Источник

    Certification.ru

    Клуб сертифицированных специалистов

    Передача Caller Id Между Cisco И Siemens

    Передача Caller Id Между Cisco И Siemens

    Сообщение Kiseloff » 20 авг 2013 17:38

    Задался вопросом как решить проблему передачи Caller ID между Cisco CUCM и Siemens HiPath 4000.
    Схема подключения:
    HiPath 4000 —E1 (ISDN)—> Cisco Gateway (3845) —IP (H323)—> CUCM

    При данной схеме не виден Caller ID на аппаратах Cisco и на аппаратах Siemens при звонках в любом направлении.

    При схеме подключения:
    HiPath 4000 —E1 (ISDN)—> Cisco Gateway (3845) —IP (H323)—> Cisco Gateway (3845) —E1 (ISDN)—> HiPath 3800

    Caller ID виден на обоих концах в обоих направлениях.

    Вопросы:
    1. Как подебажить данную ситуацию. Хотелось бы увидеть непосредственно Caller ID в дебаге.
    2. Что подкрутить, чтобы схема 1 заработала?

    Передача Caller Id Между Cisco И Siemens

    Сообщение Kiseloff » 21 авг 2013 12:36

    Может кому будет полезна данная информация (я лично потратил целый день в поисках и ничего конкретного не нашел, пришлось собирать инфу по крупицам. В конечном итоге помог старый добрый метод «научного тыка» )

    QSIG настроенный между Siemens и Cisco может быть нескольких стандартов: ECMA, ISO и LOCAL. Так вот по дефолту у Cisco выставлен LOCAL.
    Команда, которая решила проблему передачи Caller ID в обе стороны:

    interface Serial 0/0/0:15
    isdn supp-service name calling profile ROSE operation-value-tag ecma

    Источник

    Caller ID Name Delivery Issues on Cisco IOS Gateways

    Available Languages

    Download Options

    Contents

    Introduction

    Caller ID is an analog service by which a telephone central office (CO) switch sends digital information about the incoming call. The Caller ID name delivery feature for analog Foreign Exchange Station (FXS) ports was first introduced in Cisco IOS® Software Release 12.1(2)XH and is available on all later Cisco IOS software releases. This feature is available and configurable on a per-port basis to phones connected to analog FXS voice ports. This feature is also available on analog Foreign Exchange Office (FXO).

    Note: FXS ports transmit Caller ID, while FXO ports receive Caller ID. The Caller ID interoperates with analog phones, public switched telephone networks (PSTNs), private branch exchanges (PBXs), H.323 terminals (such as Microsoft NetMeeting), Cisco CallManager, and IP phones. Therefore, Caller ID can be delivered across a telephony network that consists of all or some of these devices, with some exceptions.

    Furthermore, there is a Cisco IOS feature that allows a network designer to block Caller ID from being transmitted from the FXS port, if necessary. The Caller ID is unblocked, by default, for all calls; but, Caller ID can be blocked on a per-port basis. When you turn on this feature on any given port, it blocks the Caller ID of all calls that originate from that port.

    Prerequisites

    Requirements

    Before you attempt this configuration, make sure that you understand the command references for this feature, which are described here:

    [no] caller-id enable—Enables and disables Caller ID. Default is Caller ID disabled. This enables or disables the transmission of Caller ID on an FXS port and enables or disables reception of Caller ID on an FXO port.

    [no] station-id number string —Provides a station number to use as the calling number associated with the voice port. The string parameter is optional and, if provided, is passed as the calling number when a call originates from this voice port. If this parameter is not specified, the calling number attained from a reverse-dial-peer search is used. If no Caller ID is received on an FXO voice port, this parameter is used as the calling number. The maximum number of characters that can be used for the string parameter is 15 characters.

    [no] station-id name string —Provides a station name associated with the voice port. The string parameter is passed as the calling name to the remote end when a call originates from this voice port. If no Caller ID is received on an FXO voice port, this parameter is used as the calling name. The maximum number of characters that can be used for the string parameter is 15 characters.

    [no] caller-id block—Blocks or unblocks Caller ID. The default is Caller ID unblocked. This command blocks or unblocks the Caller ID of all calls that originate from this port. This command is available only on FXS voice ports.

    [no] ring number string —This command sets the maximum number of rings to be detected before a call is answered over an FXO voice port. The ring number command is how Cisco receives the Caller ID information after two rings. For more information, refer the ring number section of Cisco IOS Voice Command Reference.

    Components Used

    This configuration was developed and tested with these software and hardware versions:

    Cisco 2600 IOS® routers with Ethernet card, analog FXS card, NM-2V module and VWIC-MFT vice-card with NM-HDV module

    A simple analog phone with RJ-11 connected to one Cisco 2600

    Any third-party vendor PBX with a T1 interface for other Cisco 2600s

    Cisco IOS versions used in the 2600s are mainline Cisco IOS® Software Release 12.2(10)

    The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

    Conventions

    Refer to Cisco Technical Tips Conventions for more information on document conventions.

    Configure

    In this section, you are presented with the information to configure the features described in this document.

    Note: In order to find additional information on the commands used in this document, use the Command Lookup Tool (registered customers only) .

    Network Diagram

    The simple telephony network in this diagram shows an example of Caller ID delivery through the LAN and the FXS port on the Cisco 2600 B side to Phone B. The Caller ID is not supported on E&M channel associated signaling (CAS) lines. In this example, Caller ID is spoofed as though it came from the CAS line, in order to send it to the FXS port. For digital lines, only ISDN lines support Caller ID delivery by default, and CAS type fgd is the only CAS type to support Caller ID delivery.

    On the Cisco AS5300 and AS5800 platforms, a feature of CAS signaling Feature Group B (FGB) allows Automatic Number Identification (ANI) to be received upon configuration of the T1. If this signaling is used, the Caller ID is automatically received on the Cisco 5300 or 5800. This feature is explained further in CAS on T1 Voice Channels.

    This configuration shows only the elements that pertain to Voice over IP (VoIP) and Caller ID commands:

    The call flow is from PBX to Phone B. In this scenario, if a call comes in to 2600 A and is delivered out to 2600 B, then the Caller ID display on Phone B is:

    Configurations

    This document uses these configurations:

    Cisco 2600 A
    Cisco 2600 B

    How to Configure SIP Extensions for Caller Identity

    In order to enable translation of the SIP header Remote-Party-ID, use the remote-party-id command in SIP UA configuration mode.

    When the remote-party-id command is enabled, if a Remote-Party-ID header is present in the incoming INVITE message, the calling name and number extracted from the Remote-Party-ID header are sent as the calling name and number in the outgoing setup message. For more information about SIP Extensions for Caller Identity, refer to SIP Extensions for Caller Identity and Privacy.

    Verify

    For verification and basic configurations of Caller ID, refer to CAS on T1 Voice Channels.

    Troubleshoot

    This section provides information you can use to troubleshoot your configuration.

    Troubleshooting Debugs and Analyzing Traces

    You can turn on several debugs in order to troubleshoot the Caller ID feature on the routers. The voice port module (VPM) signaling debugs (debug vpm signal) track the standard fxs-loopstart debugs with the Caller ID feature turned on. These debugs are analyzed from the perspective of the terminating router and the FXS port of that router; the Caller ID is received on this end.

    Debugs from Terminating Gateway 2600 B on the FXS Port

    Note: Lines of this output that are on more than one line are actually displayed as one line in the debug output.

    This is displayed on Phone B:

    When the hexadecimal Caller ID String is decoded in the example, it provides these results:

    Note: Lines of this output that are on more than one line are actually displayed as one line in the debug output.

    In the example shown, everything works fine and both Name and Number Display are properly delivered to the phone. In these two scenarios, the calling number fails to display in one case and in the other case, the name fails to display.

    Calling Number is Lost, Name is Delivered

    Note: Lines of this output that are on more than one line are actually displayed as one line in the debug output.

    When the hexadecimal Caller ID String is decoded in the example, the substring 04 01 4F translates to these:

    Calling Number is Delivered, Name is Lost

    Note: Lines of this output that are on more than one line are actually displayed as one line in the debug output.

    When the hexadecimal Caller ID String is decoded in the example, the substring 08 01 4F translates to these:

    These are the same VPM debugs for an FXO port which receives Caller ID. In the example shown, the FXS port transmits Caller ID to the phone. In the case of an FXO port, the process is reversed, but the debugs are very similar (shown here).

    Debugs for an FXO Port Receiving Caller ID Correctly

    Note: Lines of this output that are on more than one line are actually displayed as one line in the debug output.

    Источник

    Adblock
    detector