поле diversion в sip
SIP Diversion Header
Overview
The IMG supports the INVITE Diversion Header (Diversion and CC-Diversion) to support PSTN Redirecting Services (also known as Call Forwarding). The INVITE Diversion header carries information about the redirection of a call. The Diversion header prevents the pertinent SS7 or ISDN redirection information from being lost in the SS7/ISDN to SIP conversion. When SS7 redirection information is received on the incoming side, it is relayed in the Diversion header on the outgoing SIP side. The Call Flows below describe the functionality that is supported when utilizing the SIP Diversion Header. To enable or disable SIP Diversion Header refer to the SIP Headers topic.
In software 10.5.1 a new enhancement was added which includes a charge number parameter in the outgoing IAM message upon receiving an INVITE message from on the incoming SIP channel group. If the user wants to eliminate the charge number parameter, the charge number can be filtered out using the SS7 Parameters Filter object.
Scenarios
The call flow diagrams below display the supported functionality when utilizing the Diversion Header.
SS7 to SIP Call Forwarding Scenario
In the call flow below, the Redirecting number and Original called number is interworked from the SS7 to SIP. When a Redirecting number and Original Called number are present the following is true.
SS7 to SIP with NOA Scenario (10.5.3 SP9)
When an SS7 IAM is received, one of the following scenarios will occur.
If the incoming IAM message contains only the Redirecting Number parameter, the Nature Of Address parameter on the incoming IAM message will be interworked to the outgoing SIP Diversion Header as noa=x.
If the incoming IAM message contains only the Original Called Number parameter, the Nature Of Address parameter in the incoming IAM message will be interworked to the outgoing bottommost SIP Diversion Header as noa=y.
If the incoming IAM message contains both the Redirecting Number and Original Called Number, the Nature Of Address parameters will be interworked into two separate Diversion headers. The topmost Diversion Header in the SIP INVITE will contain the Nature Of Address parameter (noa=x) of the Redirecting Number. The bottommost Diversion Header in the SIP INVITE message will contain Nature Of Address parameter (noa=y) of the Original Called number.
The interworking of the Nature Of Address parameter is configured using the SIP Header Parameters object
Refer to the Call Flow below.
In the call flow below, a single SIP Diversion Header is interworked to the SS7 side. In this scenario, the following is true.
The number in the SIP Diversion Header is interworked to both the Redirecting Number and the Original Called Number.
SIP to SS7 with NOA Scenario (10.5.3 SP4.1)
When a SIP INVITE message is received and one or more Diversion Headers are present with the Nature of Address parameter, the IMG will map the values to the ISUP Redirecting and Original Called Numbers as described below.
ISDN to SIP Call Forwarding Scenario
In the call flow below the following scenario occurs.
Related Topics:
Copyright © 2017 Dialogic Corporation. All Rights Reserved.
Поле diversion в sip
Помогите решить мою задачку.
Есть 13 астериск с каналом PJSIP.
Подключен SIP-T на Ростелеком.
Два внутренних номера. Звонки ходят наружу внутри и т.д.
Соответственно аппарат кидает в Астериск такой пакетик
SIP/2.0 302 Moved Temporarily
и добавляет строку:
Diversion : ;reason=unconditional
В поле From идет внешний номер, на который сделана переадресация (все гут).
Ростелеком говорит, что в Diversion должен быть номер который изначально пришел на астериск или вообще убрать поле Diversion.
И вот чтобы я ни делал я не могу:
Убрать Diversion
Изменить поле Diversion
Прочитать поле Diversion
Пытался это делать я с помощью PJSIP_HEADER.
Более того, PJSIP_HEADER даже не может ничего прочитать из заголовка, при этом ошибок в консоли нет.
В других случаях PJSIP_HEADER работает исправно, только для Invite после Moved Temporarily не работает.
У кого какие идеи как подправить/удалить поле Diversion из Invite или как-то иначе выйти из положения?
Спасибо.
Re: Переадресация с аппарата наружу через SIP-T
На канале SIP и астериске 1.8 данная штука полечилась добавлением оператора:
SIPAddHeader(Diversion:222333;reason=no-answer);
При этом в SIP-T улетало два поля Diversion.
Попытки удалить строку Diversion от телефона в диалплане не увенчались успехом.
Re: Переадресация с аппарата наружу через SIP-T
2) Манипулировать SIP заголовками можно и нужно, не только через SIPAddHeader
3) лучше бы переадресацию делать средствами станции, сервисный код
Call Forward All Activate *72
и там много ещё
Re: Переадресация с аппарата наружу через SIP-T
1) Необходимость использования PJSIP:
— PJSIP считается наиболее правильной реализацией SIP (надеюсь исчезнут проблемы с периодической потерей регистрации Yealink).
— Можно хоть каждого SIP клиента посадить на свой порт, особенно актуально когда много удаленных офисов, хотя можно обойтись и каналом SIP.
— Сообщество движется в сторону PJSIP и скорее всего переход произойдет.
2) Даже при использовании канала SIP, он не может удалить Diversion, прилетающий с телефона (только доьавить еще один). При использовании PJSIP функции SIP_HEADER нет. К тому же SIP_HEADER не может изменить заголовок.
Спасибо за рассмотрение других вариантов, но тем не менее остается, что функциия PJSIP_HEADER в разных ситуациях работает непредсказуемо..
Re: Переадресация с аппарата наружу через SIP-T
— PJSIP считается наиболее правильной реализацией SIP (надеюсь исчезнут проблемы с периодической потерей регистрации Yealink).
— Можно хоть каждого SIP клиента посадить на свой порт, особенно актуально когда много удаленных офисов, хотя можно обойтись и каналом SIP.
— Сообщество движется в сторону PJSIP и скорее всего переход произойдет.
Re: Переадресация с аппарата наружу через SIP-T
ЗЫ: интересно, считается это багом и куда его можно заявить?
Re: Переадресация с аппарата наружу через SIP-T
Re: Переадресация с аппарата наружу через SIP-T
Re: Переадресация с аппарата наружу через SIP-T
Уф решено! Мир стоит!
В 1.8 send_diversion ни как не влияло.
В итоге функция PJSIP_HEADER работает исправно во всех случаях. Влияла опция send_diversion на канале SIP-T.
Если ее не поставить в send_diversion=no, то поле diversion перезаписывается независимо от бубнов с PJSIP_HEADER.
Re: Переадресация с аппарата наружу через SIP-T
1) Необходимость использования PJSIP:
— PJSIP считается наиболее правильной реализацией SIP (надеюсь исчезнут проблемы с периодической потерей регистрации Yealink).
Использование дополнительного поля в SIP протоколе «Diversion» или просто RDNIS
RDNIS – Redirected Dialed Number Identification Service. В простой терминологии «промежуточный номер при переадресации». Получить данное значение от оператора связи 2-я способами: При подключении по потоку Е1. При подключении по SIP протоколу.
Сразу хочу сказать, что получение данной информации есть дополнительным информационным сообщением в том или ином протоколе сигнализации. Соответственно оператор связи оставляет за собой право передачи данной информации клиенту, плюс что не мало важно напрямую зависит от промежуточного оборудование в которое включен клиент.
Сразу скажу, что ТП оператора связи моего корпоративного подключения подразумевают нетарифицированный обьем услуг на другие сети и сети фиксированной связи.
Со временем 8-и портового шлюза стало не достаточно, приобретать дополнительный шлюз не было рационально, я начал изучать вопрос RDNIS.
Задав вопрос оператору связи, я был включен по DSS1, поток PRI о возможности подставить данную информацию в мой поток, на что мне оператор ответил что необходимо стыковаться по ОКС 7. Да, Asterisk в open source поддерживает ОКС 7, но:
В связи с этим данным способ не подходит.
Есть второй вариант и это в SIP сообщении дополнительное поле Diversion.
Задав вопрос о возможном включении по SIP. Ответ положителен от оператора связи. Номер получил фиксированной связи, потому как мобильные маски строго под сеть GSM. Произвели включение и проверяем получаем ли мы необходимую информацию.
Настройка подключения оператора связи по SIP:
Настройка маршрутизации звонков:
При входящем звонке проверяем на доп. поле и если оно есть, то обращаемся к БД что бы узнать действительно ли сотрудник установил переадресацию и если «да», то производим набор через оператора который предоставляет международное направление (с возможностью подстановки clip). Что в данном случаи вообще великолепно для сотрудника находящегося в роуминге.
INVITE sip:151515@2.2.2.2:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bKnkoj7ljjo88bl7hoy7vi7e788
User-Agent: Huawei SoftX3000 V300R010
o=HuaweiSoftX3000 29333672 29333672 IN IP4 1.1.1.1
m=audio 40384 RTP/AVP 8 101
Как видим, SIP Header Diversion отсутствует.
INVITE sip:151515@2.2.2.2:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bKev7hvxbjncukvj8hy7hkycncl
User-Agent: Huawei SoftX3000 V300R010
Diversion: Anonymous ;reason=unconditional;counter=1
o=HuaweiSoftX3000 29333914 29333914 IN IP4 1.1.1.1
m=audio 40640 RTP/AVP 8 101
Вот что нам было и необходимо.
Александр Чалый, специально для «Вокс Линк»
Tao, Zen, and Tomorrow
We all want to think that we are unique in some way and I expect that most people can find a few things about themselves that are different from the people around them. Sometimes those differences can be life defining. Take a look at most great basketball players and tell me that their height wasn’t a major factor in being able to play at the professional level. The same can be said for an NFL tackle where the average weight is above 300 pounds. You can be a tough-as-nails 180-pound badass, but you won’t get a shot at the big leagues unless you put on some pounds.
So, what makes me unique? At just shy of 6’ 2” I am too short for basketball and no one in their right mind would ever put me on a football field as anything other than a tackling dummy.
Sadly, I’m not even unique in the field of communications. There are others that know more about this stuff than I will ever dream to know.
However, there is something that makes me different from just about everyone else on this planet.
I was born in Arizona and spent my childhood and young adult years living in the Phoenix valley (Scottsdale, Mesa, and Tempe). That in itself isn’t unique, but the fact that I now live in Minnesota makes me quite the rarity. Let’s face it, there are lots of Minnesotans in Arizona, but you will be hard pressed to find the opposite. I never have.
Simply put, my uniqueness is based on diversion. I started out life in Arizona, was happy as a clam living there, met a Minnesota girl who became my wife, and found myself diverted to Minnesota.
Which leads me to today’s topic of discussion. The SIP Diversion header.
Okay, that’s a stretch, but cut me some slack. It’s hard coming up with new blog subjects and making them sound personal.
The SIP Diversion Header
RFC 5806 defines SIP diversion as follows:
This usually boils down to the scenario where A calls B and A is redirected (not transferred) to C.
Imagine Sarah setting call forward on her SIP telephone to send all incoming calls to Debbie. Now, when Andrew calls Sarah, his call will be automatically sent to Debbie. Debbie’s SIP telephone will know that the call was diverted by the presence of a Diversion header in the INVITE request she receives from Andrew.
Who inserted the Diversion header? It won’t be Andrew since he is unaware of the state of Sarah’s telephone. It won’t be Sarah since her telephone never saw Andrew’s call. It certainly can’t be Debbie since it’s her telephone that is ringing. This means that it must be something between Andrew and Debbie.
That something will be some form of a Back-to-Back User Agent (B2BUA) and in most cases it will be a SIP proxy that is aware of the forward conditions of the endpoints it serves. The Diversion header will be added by the proxy when it sees Andrew’s INVITE to Sarah. That altered INVITE will then be proxied to Debbie.
You can read all about B2BUAs in my article, The Back to Back User Agent (B2BUA).
In my example, I stated that Sarah’s telephone was forwarded to Debbie. Of course, there are a number of different call forward conditions. In the SIP world, these are designated as diversion-reasons with the following permissible values:
Additionally, a Diversion header supports three other parameters:
The following is an example of a fully populated Diversion header:
Anyone receiving an INVITE with this header knows that 2000 was the originally called number, no privacy was applied, the call was forwarded due to a no answer condition, this is the only diversion, and the diversion number was user provided.
A single INVITE may contain multiple Diversion headers. Those headers are ordered such that the last or most recent diversion is at the top of the list and all subsequent diversions are below it.
Making SIP Trunks Happy
In the past, I have encountered situations that required a Diversion header that had nothing to do with call forwarding. The most common is when you need to call out through a carrier SIP trunk and the From header in the INVITE contains a number not provisioned by the carrier. The carrier would look at the From value, not recognize it, and subsequently reject the call. In some cases, a Diversion header can be used to provide the carrier with a number that it does recognize.
The reasons why the carrier might reject the call are varied, but the most common one I’ve encountered is that carriers need to see a number in its pool of DIDs to properly handle 9-1-1 calls. The value in the Diversion header can be used to satisfy that requirement.
Mischief Managed
This article was meant to be an introduction to the Diversion header and I hope that I accomplished that. You are more than welcome to dig through the SIP RFCs for a deeper explanation, but for most of you that won’t be necessary.
Поле diversion в sip
This appendix describes the SIP Diversion Header Implementation for Redirecting Number feature that is introduced in Cisco IOS Release 12.1(5)XM. In addition to the SIP Diversion Header Implementation for Redirecting Number feature, this appendix describes the SIP gateway ability to process a SIP 3xx Redirection response after the receipt of a SIP 18 x Information response.
SIP Diversion Header Implementation for Redirecting Number
The SIP Diversion Header Implementation for Redirecting Number feature provides support for a new SIP header field; Call Control (CC)-Diversion. The CC-Diversion header field enables the SIP gateway to pass call control redirecting information during the call setup. Call control redirection is the redirection of a call based on a subscriber service such as call forwarding. Call redirection information is information is typically used for Unified Messaging and voice mail services to identify the recipient of a message. Call control rediversion information can also be used to support applications such as automatic call distribution and enhanced telephony features such as Do Not Disturb and Caller ID.
If generated by the SIP gateway during call process, the CC-Diversion header field is based on the contents of the Redirecting Number Information Element (IE) in the ISDN Setup message. In addition, information such as the reason the call was redirected is included in the CC-Diversion header field.
Figure B-1 illustrates a call flow for this feature.
SIP Gateway 3xx Redirection Response Processing after 18x Information Responses
With Cisco IOS Release 12.1(5)XM, SIP gateways can process SIP 3 xx Redirection responses after a 18 x Information response has been received.
Figure B-2 illustrates the SIP gateway method of:
Gateway-to-Gateway Call—Redirection with CC-Diversion
Figure B-1 illustrates a successful gateway-to-gateway call setup with call redirection with CC-Diversion.
In this scenario, the three end users are identified as Alice at phone A, Bob at phone B, and Carol at phone C. Alice at phone A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. SIP gateway 1 is using a SIP redirect server. Bob at phone B and Carol at phone C are located at PBX B. PBX B is connected to SIP gateway 2 via a T1/E1. SIP gateway 1 is connected to SIP gateway 2 over an IP network.
The call flow scenario is as follows:
1. Bob at phone B has delegated his calls to Carol at phone C.
1. Alice at phone A initiates a call with Bob via SIP gateway 1that is using a SIP proxy server.
2. The proxy server returns Carol at SIP gateway 2 as a contact location for Bob.
3. Gateway 1 initiates call with Carol.
4. Carol answers the call.
Figure B-1 SIP Gateway-to-SIP Gateway—Call Redirection with CC-Diversion
Setup—PBX A to SIP gateway 1
Call Setup is initiated between PBX A and SIP gateway 1.
Call Proceeding—SIP gateway 1 to PBX A
SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
INVITE—SIP gateway 1 to SIP proxy server
GW1 sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session.
In the INVITE request:
302 Moved Temporarily—SIP proxy server to SIP gateway 1
The SIP proxy server determines that Bob’s calls have been configured to be redirected to Carol at phone C via GW2. The SIP proxy server sends an 302 Moved Temporarily message to GW1.
In the 302 Moved Temporarily message, Carol at GW2 is added as the Contact and there are two CC-Diversion header fields included; one for Alice at GW1 (IP address or domain name) and one for Bob at GW2 (IP address or domain name).
ACK—SIP gateway 1 to SIP proxy server
An ACK message is sent from GW1 to the SIP proxy server.
INVITE—SIP gateway 1 to SIP gateway 2
SIP gateway 1 sends an INVITE request to Carol at phone C via GW2. The INVITE request contains two CC-Diversion headers; one for Alice at GW1 (IP address or domain name) and one for Bob at GW2 (IP address or domain name).
Setup—SIP gateway 2 to PBX B
SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with Carol via PBX B. In the Call Setup, the ISDN Redirecting Number IE is generated using the contents of the top CC-Diversion header field; in this case, Bob at GW2.
Call Proceeding—PBX B to SIP gateway 2
PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
Alerting—PBX B to SIP gateway 2
PBX B locates Carol at phone C and sends an Alert message to SIP gateway 2. Carol’s phone begins to ring.
180 Ringing—SIP gateway 2 to SIP gateway 1
SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, Carol at phone C.
Alerting—SIP gateway 1 to PBX A
SIP gateway 1 sends an Alert message to PBX A. Alice hears ringback tone.
At this point, a one-way voice path is established between SIP gateway 1 and PBXA and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
Connect—PBX B to SIP gateway 2
Carol answers phone. PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
200 OK—SIP gateway 2 to SIP gateway 1
SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
If Carol via SIP gateway 2 supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and Alice’s media capability in the 200 OK response. If Carol at SIP gateway 2 does not support the media capability advertised by Alice at SIP gateway 1, SIP gateway 2 sends back a 400 Bad Request response with a «Warning: 304 Codec negotiation failed» header field.
Connect—SIP gateway 1 to PBX A
SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
Connect ACK—PBX A to SIP gateway 1
PBX A acknowledges SIP gateway 1’s Connect message.
ACK—SIP gateway 1 to SIP gateway 2
SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 200 OK response has been received.
The call is now in progress over a two-way voice path via RTP.
Connect ACK—SIP gateway 2 to PBX B
SIP gateway 2 acknowledges PBX B’s Connect message.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
Gateway-to-Gateway Call—SIP 3 xx Redirection Response After Receipt of a SIP 18 x Information Response
Figure B-2 illustrates a successful gateway-to-gateway call setup in which a SIP 3xx Redirection response is processed after the receipt of a SIP 18 x Information response.
In this scenario, the three end users are identified as Alice at phone A, Bob at phone B, and Carol at phone C. Alice at phone A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. SIP gateway 1 is using a SIP redirect server. Bob at phone B and Carol at phone C are located at PBX B. PBX B is connected to SIP gateway 2 via a T1/E1. SIP gateway 1 is connected to SIP gateway 2 over an IP network.
The call flow scenario is as follows:
1. Bob at phone B has delegated his calls to Carol at phone C.
1. Alice at phone A initiates a call with Bob via SIP gateway 1that is using a SIP proxy server.
2. The proxy server returns Carol at SIP gateway 2 as a contact location for Bob.
3. Gateway 1 initiates call with Carol.
4. Carol answers the call.
Figure B-2 Gateway-to-Gateway Call—Call Redirection after Receipt of a SIP 18 x Response
Setup—PBX A to SIP gateway 1
Call Setup is initiated between PBX A and SIP gateway 1.
Call Proceeding—SIP gateway 1 to PBX A
SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
INVITE—SIP gateway 1 to SIP proxy server
GW1 sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session.
In the INVITE request:
100 Trying—SIP proxy server to SIP gateway 1
The SIP proxy server sends a 100 Trying to GW1.
183 Session Progress—SIP proxy server to SIP gateway 1
The SIP proxy server sends a 180/183 Session Progress response to SIP gateway 1 (GW1).
Timer expires message—SIP proxy server to SIP gateway 1
No-answer timer expires on the proxy server. Proxy server sends a 302 to GW1.
ACK—SIP gateway 1 to SIP proxy server
GW1 sends an ACK to the proxy server for the 302.
302 Moved Temporarily—SIP proxy server to SIP gateway 1
The SIP proxy server determines that Bob’s calls have been configured to be redirected to Carol at phone C via GW2. The SIP proxy server sends an 302 Moved Temporarily message to GW1.
In the 302 Moved Temporarily message, Carol at GW2 is added as the Contact and there are two CC-Diversion header fields included; one for Alice at GW1 (IP address or domain name) and Bob at GW2 (IP address or domain name).
INVITE—SIP gateway 1 to SIP gateway 2
SIP gateway 1 sends an INVITE request to Carol at phone C via GW2. The INVITE request contains two CC-Diversion headers; one for Alice at GW1 (IP address or domain name) and Bob at GW2 (IP address or domain name).
Setup—SIP gateway 2 to PBX B
SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with Carol via PBX B. In the Call Setup.
Call Proceeding—PBX B to SIP gateway 2
PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
Alerting—PBX B to SIP gateway 2
PBX B locates Carol at phone C and sends an Alert message to SIP gateway 2. Carol’s phone begins to ring.
180 Ringing—SIP gateway 2 to SIP gateway 1
SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, Carol at phone C.
Alerting—SIP gateway 1 to PBX A
SIP gateway 1 sends an Alert message to PBX A. Alice hears ringback tone.
At this point, a one-way voice path is established between SIP gateway 1 and PBXA and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
Connect—PBX B to SIP gateway 2
Carol answers phone. PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
200 OK—SIP gateway 2 to SIP gateway 1
SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
If Carol via SIP gateway 2 supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and Alice’s media capability in the 200 OK response. If Carol at SIP gateway 2 does not support the media capability advertised by Alice at SIP gateway 1, SIP gateway 2 sends back a 400 Bad Request response with a «Warning: 304 Codec negotiation failed» header field.
Connect—SIP gateway 1 to PBX A
SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
Connect ACK—PBX A to SIP gateway 1
PBX A acknowledges SIP gateway 1’s Connect message.
ACK—SIP gateway 1 to SIP gateway 2
SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 200 OK response has been received.
The call is now in progress over a two-way voice path via RTP.
Connect ACK—SIP gateway 2 to PBX B
SIP gateway 2 acknowledges PBX B’s Connect message.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
Posted: Wed Oct 1 00:23:38 PDT 2003
All contents are Copyright © 1992—2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.