Процесс установки соединения с вызовом по требованию

используем описанный выше сценарий для того, чтобы рассмотреть процесс установки соединения с вызовом по требованию. для определенности будем считать, что хост с адресом 173.75.73.5 пытается получить доступ к ресурсам хоста с адресом 173.75.72.10. при этом выполняется следующая последовательность действий:
1. пакеты от 173.75.73.5, предназначенные для 173.75.72.10, передаются маршрутизатору 1.
2. маршрутизатор 1 получает пакет от 173.75.73.5 и проверяет собственную таблицу маршрутизации. маршрут к 173.75.72.10 предписывает передавать пакеты через интерфейс dd_spb.
3. маршрутизатор 1 проверяет состояние интерфейса dd_spb и обнаруживает его в разъединенном состоянии.
4. маршрутизатор 1 извлекает информацию о конфигурации интерфейса dd_spb с вызовом по требованию.
5. полученная информация используется маршрутизатором 1 для инициации соединения с вызовом по требованию. маршрутизатор 1 использует модем, подключенный к сом1, чтобы набрать номер (812)765-4321 begin_of_the_skype_highlighting (812)765-4321 end_of_the_skype_highlighting.
6. маршрутизатор 2 отвечает на входящий вызов.
7. маршрутизатор 2 запрашивает идентификационную информацию по входящему соединению.
8. маршрутизатор 1 посылает имя учетной записи пользователя "dd_moscow" и соответствующий ей пароль.
9. после получения идентификационной информации маршрутизатор 2 проверяет имя пользователя и пароль в базе данных системы безопасности windows и определяет, что маршрутизатор 1 имеет разрешение на установление входящего соединения.
10. теперь маршрутизатор 2 должен определить, является ли субъект, установивший входное соединение, сетевым клиентом или маршрутизатором, устанавливающим соединение с вызовом по требованию. маршрутизатор 2 просматривает список интерфейсов с вызовом по требованию и ищет интерфейс, который соответствует имени пользователя, посланному маршрутизатором 1 как часть идентификационной информации. маршрутизатор 2 находит интерфейс с вызовом по требованию "dd_moscow", который соответствует имени пользователя.
11. маршрутизатор 2 переводит интерфейс с вызовом по требованию от dd_moscow в состояние "соединен".
12. маршрутизатор 1 передает пакет от пользователя с адресом 173.75.73.5 через соединение с вызовом по требованию на маршрутизатор 2.
13. маршрутизатор 2 получает пакет и пересылает его хосту с адресом 173.75.72.10.
14. хост с адресом 173.75.72.10 отправляет на маршрутизатор 2 ответ на запрос об установлении соединения, сделанный хостом с адресом 173.75.73.5.
15. маршрутизатор 2 получает пакет, предназначенный для 173.73.75.5, и проверяет таблицу маршрутизации: маршрут к 173.75.73.5 найден, используется интерфейс dd_moscow.
16. маршрутизатор 2 проверяет состояние интерфейса dd_moscow и определяет, что он находится в состоянии "соединен".
17. маршрутизатор 2 передает пакет маршрутизатору 1.
18. маршрутизатор 1 передает пакет пользователю по адресу 173.75.73.5.
если имя пользователя в идентификационной информации не совпадают с именем соответствующего интерфейса с вызовом по требованию, объект вызова определяется как сетевой клиент, что может привести к проблемам маршрутизации. допустим, в рассмотренном выше примере маршрутизатор 1 использует строку "dialuprouterl" в качестве имени учетной записи пользователя, передаваемого в процессе аутентификации пользователя (предположим также, что dialuprouterl реально существующая учетная запись, имеющая разрешение на установление входящего соединения). в этой ситуации маршрутизатор 1 будет распознан как сетевой клиент, а не как маршрутизатор. пакеты от хоста с адресом 173.75.73.5 будут отправляться хосту с адресом 173.75.72.10, так же как и было описано ранее. однако ответные пакеты от 173.75.72.10 к 173.75.73.5 не будут доставлены, поскольку маршрутизатор 2 после проверки таблицы маршрутизации определит, что интерфейс, который необходимо использовать, — dd_moscow. но dd_moscow находится в разъединенном состоянии. в соответствии с конфигурацией для dd_moscow должен использоваться порт com2. однако com2 в настоящее время используется маршрутизатором 2 для сетевого клиента (за который ошибочно был принят маршрутизатор 1). следовательно, процесс установки соединения для dd_moscow оканчивается неудачей, и ответные пакеты от 173.75.72.10 к 173.75.73.5 теряются.