Applying for Connecting to a Self-Owned Access Code

Prerequisites

To connect enterprise self-owned access codes that support SIP to the CEC, the following conditions must be met:

• Device: The device supports the full SIP protocol and has a fixed public IP address and port number.
• Network quality: The voice call quality depends on the stability of the data network. The packet loss rate between the enterprise and the CEC must be less than 1%, the network jitter must be less than or equal to 60 ms, and the delay must be less than 200 ms. If the network does not meet this requirement, the voice may be intermittent and the other party cannot hear clearly.
• Network bandwidth: The voice media protocol used by the CEC is G.711 A, the average traffic is 100 Kbit/s, and the uplink and downlink traffic is equal. Bandwidth is calculated as follows: Network bandwidth = (Number of concurrent users x 100 Kbit/s)/1024

  Assume that there are 100 concurrent customers, the required bandwidth is (100 x 100 Kbit/s)/1024, that is, 9.7 Mbps. The required uplink and downlink bandwidth is 10 Mbit/s.

• Access code: Access codes that support SIP with signaling IP addresses and port numbers can be connected.
  • Common fixed-line phone number and 95 number: Enterprises can submit applications themselves or Huawei helps enterprises submit applications to carriers.
  • 400 number: You can directly apply for connecting to access codes that support SIP. For access codes that do not support SIP, contact the carrier to configure the forwarding of calls to a SIP fixed-line phone and apply for connecting to this self-owned access code. Common virtual numbers and mobile numbers cannot be connected.

Context

Introduction to SIP

Session Initialization Protocol (SIP) is a multimedia communication protocol developed by the Internet Engineering Task Force (IETF,https://www.ietf.org/). It is a text-based application-layer control protocol and is used to establish, modify, and release sessions of one or more participants. SIP is independent of transmission-layer protocols, and can be carried over different transmission protocols, such as UDP, TCP, TLS, and SCTP. SIP alone cannot complete a multimedia call. It establishes a complete multimedia communication system with other protocols. It must cooperate with protocols such as RTP/RTCP, SDP, MGCP, and DNS to complete a multimedia session process.

SIP only describes how to establish, modify, or release a session but does not describe the session contents. Therefore, SIP can carry any session contents, such as voices, videos, and games.

SIP protocol example

The SIP protocol content varies according to the line and scenario. The following is the SIP protocol content in a voice call successfully initiated by the CEC. You can refer to this example to understand the SIP protocol in use.

INVITE sip:18012345678@10.11.56.68:5060;user=phone SIP/2.0
/*Request line. It consists of Method, Request-URI, and SIP Version. The Request-URI header field specifies the called number 18012345678 obtained by the UAP.*/
/*SIP Header-start*/
Via: SIP/2.0/UDP 10.11.56.61:5060;branch=z9hG4bK9njqrkwmmvg6or9gnjml6hvwv;Role=3;Hpt=8e48_16
/*Message header. It is used to record the path that a request passes through, so that the response can be correctly returned along this path. The SIP URI carried in the Via header field identifies the host name or network address of the customer who initiates the request. The UAP obtains the signaling address of the peer end from the Via header field, for example, 10.11.56.61:5060.*/
Record-Route: <sip:10.11.56.61:5060;transport=udp;lr;Hpt=8e48_16;CxtId=4;TRC=ffffffff-ffffffff;X-HwB2bUaCookie=2717>
/*Forcible routing. It is used to force a request to pass through a series of proxies.*/
Call-ID: isbcjiwwievb2zvydwesyf2w0dxvdzsszefd@UAP9600
/*Unique call ID. The value is a string of random characters.*/
From: <sip:02160123456@10.11.56.61;user=phone>;tag=yv20ze22-CC-57
/*Initiator of the request. The calling number can be obtained. For the first message, only the From field contains tag, and the To field does not contain tag.*/
To: <sip:18012345678@10.11.56.68;user=phone>
/*Recipient of the request. During registration, it specifies the public customer to be registered. During a session, it specifies the recipient of the request and carries the URI of the recipient. For details about the tag field, see the description of the From field. The To header field in an initial request may not carry tag, but any request or response in a session must carry tag. IP address:Port number obtained by the UAP from the To field is the local signaling address. The UAP obtains the original called number from the Historyinfo or Diversion field first. If the Historyinfo or Diversion field does not contain the required information, the UAP obtains the original called number from the To field.*/
CSeq: 1 INVITE
/*Sequence number of a transaction. The sequence number is incremented by 1.*/
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
/*Header field. It is used to list all SIP methods supported by the UA.*/
Contact: <sip:02160123456@10.11.56.61:5060;transport=udp;Hpt=8e48_16;CxtId=4;TRC=ffffffff-ffffffff>
/*Address for subsequent direct communication with the customer. The SIP URI indicates the address for receiving responses.*/
Max-Forwards: 69
/*Maximum times that a request can be forwarded before it arrives at the destination. The value decreases by 1 each time the request is forwarded. This header field is used to prevent proxy resources from being continuously consumed when a loop occurs. The value ranges from 0 to 255. The recommended value is 70.*/
Supported: 100rel
/*All SIP extension methods supported by the UAC or UAS.*/
User-Agent: Huawei UAP9600 V100R005C00
Content-Length: 236
//Length of the message body, in bytes.*/
Content-Type: application/sdp
/*Type of the message body. In this example, the type is SDP.*/
/*SIP Header-end*/

/*SIP Body-start*/
v=0
/*Protocol version. In this example, the protocol version is 0. (The protocol version used by the SDP is 0.)*/
o=- 929076 929076 IN IP4 10.11.56.61
/*The first parameter: - indicates the name of the session initiator. This parameter is optional.
The second parameter: 929076 indicates the session identifier of the calling party.
The third parameter: 929076 indicates the version of the calling party. When the session data changes, the version number is increased by 1.
The fourth parameter: IN indicates the network type Internet. Only this type of network is supported.
The fifth parameter: IP4 indicates the IP address type. IPv4 and IPv6 are supported.
The sixth parameter: 10.11.56.61 indicates the IP address of the session initiator, which is a signaling plane IP address.*/
s=SBC call
/*Name of the current session.*/
c=IN IP4 10.11.56.61
/*Connection information. The "c=" line identifies the media receiving address of the UE. If the media-level "c=" line also exists, the media-level "c=" line is used. This parameter is mandatory in any case.
The first parameter: IN indicates the network type Internet. Only this type of network is supported.
The second parameter: IP4 indicates the IP address type. IPv4 and IPv6 are supported.
The third parameter: 10.11.56.61 indicates the actual IP address used by multimedia streams.*/
t=0 0
/*The first parameter indicates the start time, and the second parameter indicates the stop time. The start time and stop time are Network Time Protocol (NTP) time in decimal format. If the values are both 0, the session is persistent.*/
m=audio 59354 RTP/AVP 8 0 97
/*m=<media> <port> <transport> <fmt list>. media indicates the media type, which can be audio or video. Currently, audio, video, application, data, and control are defined. port indicates the media port number. transport indicates the transport protocol. Currently, RTP/AVP is used. fmt list indicates the format list.*/
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
/*rtpmap indicates the keyword, which is in the format of {PT value} {Stream name}/{Sampling rate}.*/
a=rtpmap:97 telephone-event/8000
a=ptime:20
/*Media encapsulation duration (media duration that can be encapsulated in each packet, in milliseconds). In this example, the duration is 20 ms.*/
a=fmtp:97 0-15
a=sendrecv
/*Media direction. In this example, the media direction is bidirectional. The media direction can be inactive, sendonly, recvonly, or sendrecv.*/
/*SIP Body-end*/

• SIP header is a signaling message used by the sending party to notify the receiving party of the basic information about the call.

  The signaling messages may be understood as:

  Call 10.11.56.68:5060.

  I'm sending you a SIP message from 10.11.56.61:5060.

  The call ID is xxxx.

  The call is from 10.11.56.61:5060.

  I need to send the message to 10.11.56.68:5060.

  This is the first Invite message sent in the call request.

  If you receive the message, reply to me at 10.11.56.61:5060.

  This is Huawei UAP9600 V100R005C00. You can reply to me with INVITE, ACK, BYE, and other messages.

  The signaling message contains 236 characters in the SDP format.

• The SIP body is a media message, that is, SDP. Media messages are mandatory in SIP messages. Signaling messages only enable the sending party and receiving party to know that they are connected. Media messages enable both parties to know the specific content of the messages.

  The media messages may be understood as:

  My version is 0.

  The message is sent to you through the signaling address 10.11.56.61, and the media address is 10.11.56.61 (the server that processes the signaling may be different from the server that processes the media). The audio media stream port is 10002, and data is transmitted using RTP. The video media stream port is 10004, and data is also transmitted using RTP.

  Not all terminals support video media. Therefore, when a SIP message is received, the peer end may receive only the audio media information. This is determined based on the negotiation result.

  NOTICE:

  Currently, the supported media transmission type is RTP/AVP, that is, the UDP channel is used to ensure the real-time audio and video transmission. The TCP-based RTP/SAVP media transmission type is not used.

Common SIP request and response messages are as follows.

NOTICE:

• The CEC side uses the OPTIONS request to query the information and functions of the called party every minute to check whether the link status is normal. The link is considered normal and calls can be made only when the enterprise side returns a 200ok response.
• When the PRACK request is used for renegotiation, the CEC side requires that the 18x message (for example, 180 ringing) returned by the peer end contain the Require:100rel field and the INVITE request sent by the peer end contain the Supported:100rel field. Otherwise, no sound can be heard during the call.
• When the CEC side uses the UPDATE request for renegotiation, this mode is used for a normal call with an agent. When the INVITE request is used for renegotiation, this mode is used for the call that is connected to the intelligent IVR or transferred through the common IVR. Some carriers do not support renegotiation using the second INVITE request. As a result, some functions, such as the virtual number service, are unavailable.

Introduction to the call process

The process for a customer to initiate an incoming call to the CEC is as follows:

• The customer initiates a call and sends an INVITE request to the SBC of the CEC.
• The CEC side returns a ringing message and a link connection success (200) message.
• After receiving the message, the customer side returns a final response to the INVITE request.
• The CEC side receives the reply and sends a renegotiation message to the customer side.
• After receiving the message, the customer side returns a link connection success (200) message.
• After the CEC returns a response to the request, the customer and agent start a conversation.

Figure 1 Call process

Business Scenario

The solution for connecting enterprise self-owned access codes that support SIP to the CEC is as follows:

Figure 2 Connecting to a self-owned access code that supports SIP

Typical scenario 1

The enterprise has local access code resources and directly connects to the CEC.

Connection solution:

1. The enterprise applies for access code resources from the carrier. The resource type can be E1, private line, or SIP.
2. After the application is successful, the enterprise needs to use the local voice gateway to convert the non-SIP lines of the carrier to the SIP lines for the communication with the public cloud SBC platform of the CEC. For details about the devices, see the local device recommendation in FAQs > Product Consulting.
3. After referring to the procedure of applying for connecting to a self-owned access code, the enterprise sends an email to the CEC operations personnel to apply for the signaling IP address, port number, and media port number of the CEC, which are used to set the whitelist on the local firewall and connect to the line.

Typical scenario 2

The enterprise applies for access codes that support SIP from the carrier, and the carrier interconnects with Huawei.

Connection solution:

1. The enterprise applies for access code and line resources from the carrier. The resource type can only be SIP.
2. After access codes are successfully applied for, the enterprise submits an application to the CEC requiring Huawei to directly interconnect with the carrier. The enterprise does not need to connect to the access codes and lines.

Procedure

Perform the following steps to add a self-owned access code.

1. Log in to Huawei Cloud.
2. Choose Service List > Business Applications > Cognitive Engagement Center.
3. Choose Resource Management > Access Code.
4. Click the Self-Owned Access Code tab page and click Click here to apply for connecting to a self-owned access code. in the upper right corner. On the page that is displayed, set the access code, signaling and media IP addresses and port numbers, and click OK.

Follow-up Procedure

You need to wait for the CEC operations personnel to configure the connection between Huawei Cloud and the self-owned access code. After the configuration is complete, the connection status of the access code is Completed on the Self-Owned Access Code page. You can click Associate Call Center Instance to associate the access code with an existing call center instance.