Cisco Systems WRP400 Manual Do Utilizador
Configuring Voice Services
Secure Call Implementation
ATA Administration Guide
73
4
The signing agent is implicit and must be the same for all ATAs that communicate
securely with each other. The public key of the signing agent is pre-configured into
the ATA device by the administrator and is used by the ATA device to verify the
Mini-Certificate of its peer. The Mini-Certificate is valid if it has not expired, and it
has a valid signature.
securely with each other. The public key of the signing agent is pre-configured into
the ATA device by the administrator and is used by the ATA device to verify the
Mini-Certificate of its peer. The Mini-Certificate is valid if it has not expired, and it
has a valid signature.
The ATA device can be configured so that, by default, all outbound calls are either
secure or not secure. If secure by default, the user has the option to disable
security when making a call by dialing *19 before dialing the target number. If not
secure by default, the user can make a secure outbound call by dialing *18 before
dialing the target number. However, the user cannot force inbound calls to be
secure or not secure; that depends on whether the caller has security enabled or
not.
secure or not secure. If secure by default, the user has the option to disable
security when making a call by dialing *19 before dialing the target number. If not
secure by default, the user can make a secure outbound call by dialing *18 before
dialing the target number. However, the user cannot force inbound calls to be
secure or not secure; that depends on whether the caller has security enabled or
not.
The ATA device will not switch to secure mode if the CID of the called party from
its Mini-Certificate does not agree with the user-id used in making the outbound
call. The ATA device performs this check after receiving the Mini-Certificate of the
called party
its Mini-Certificate does not agree with the user-id used in making the outbound
call. The ATA device performs this check after receiving the Mini-Certificate of the
called party
Secure Call Details
Looking at the second stage of setting up a secure call in greater detail, this stage
can be further divided into two steps.
can be further divided into two steps.
STEP 1
The caller sends a “Caller Hello” message (base64 encoded and embedded in the
message body of a SIP INFO request) to the called party with the following
information:
message body of a SIP INFO request) to the called party with the following
information:
•
Message ID (4B)
•
Version and flags (4B)
•
SSRC of the encrypted stream (4B)
•
Mini-Certificate (252B)
Upon receiving the Caller Hello, the called party responds with a Callee Hello
message (base64 encoded and embedded in the message body of a SIP
response to the caller’s INFO request) with similar information, if the Caller Hello
message is valid. The caller then examines the Callee Hello and proceeds to the
next step if the message is valid.
message (base64 encoded and embedded in the message body of a SIP
response to the caller’s INFO request) with similar information, if the Caller Hello
message is valid. The caller then examines the Callee Hello and proceeds to the
next step if the message is valid.