WiMAX_CPE_VoIP

CPE VoIP Interoperability Testing
WHITE PAPER

2 WHITE PAPER: CPE VoIP InteroperabilityTesting
Authors
Arjun Nanjundappa Mail ID: arjunn@motorola.com
Sathish A C Mail ID: sathishac@motorola.com
Arjun and Sathish have spent the last two years working on Motorola’s WiMAX CPEi600‘s VoIP development and
interoperability project.
Abstract
VoIP service in the Internet platform is becoming popular because of its low cost with attractive features.
VoIP clients like CPE cannot interoperate with different VoIP Servers directly due to reasons highlighted in
this paper. This paper provides an insight into the issues experienced during the interop testing of CPE with
various commercial VoIP application Servers. In addition to this, it also provides some guidelines and best
practices that can be followed before IOT is carried out and emphasizes the need for IOT with different VoIP
application Servers.

Introduction
Voice over IP (VoIP) is a technology for transporting voice communication over IP networks, such as the
Internet. Much of the information in this document is gleaned from experiences related to the VoIP software
development and testing of Motorola’s Buckeye WiMAX CPE (CPEi600), which was carried out at Motorola.
WiMAX CPE is a user end device used in the customer’s home /office which provides residential gateway and
telephony VoIP services through 802.16e wireless connections. It provides basic telephony and supplementary
features like call transfer, call forwarding, and conferencing. These basic VoIP services and supplementary
services are provided using Session Initiation Protocol (SIP) as a VoIP protocol.
SIP is an application–layer control protocol that can establish, modify, and terminate multimedia sessions
such as Internet telephony calls. SIP supports name mapping and redirection services, which in turn supports
personal mobility: users can maintain a single, externally visible identifier regardless of their network location.
WiMAX-CPE uses appropriate, guaranteed Quality of Service to provide VoIP services, so that delay sensitive
VoIP service is not impacted when users take advantage of other data services like web browsing or data
transfer. It providesVoIP Services through extended real-time polling service (ERTPS) flows. ERTPS is designed
for real-time traffic with variable data rates, such as VoIP service with silence suppression.
VoIP service allows the convergence of networks.This implies that a number ofVoIP networks have connections
to the public Internet. CPE combines voice and data traffic into a single converged network, so we do ensure
manageability, performance, and full security, including authorization, authentication, confidentiality, and
integrity. CPE authenticates SIP messages based on Message-Digest Algorithm (MD5).
WiMax CPE Network
The network diagram shown below illustrates the CPE equipment’s network connection to the outside network.
It shows a typical configuration, although there may be variations from system to system. The following steps
outline the sequence involved in establishing network entry.
The first step for the CPE is system acquisition. The CPE scans for downlink channels and establishesa.
synchronization with the Base station. Then, it obtains transmit parameters, such as the channel and time
slot information, by listening to the network system information broadcast.
CPE then starts the Ranging process. Ranging is the process that allows CPE to obtain precise timingb.
offset, adjust the transmit power and tune the frequency.
CPE then negotiates basic capabilities with the Base station. The CPE informs the Base station about itsc.
basic capabilities, such as physical parameters, bandwidth allocation, and supported security parameters.
The Base station will schedule the radio resources accordingly.
The CPE now authenticates and Registers itself with the network. Authentication involves user deviced.
authentication and mutual authentication between the CPE and the network. The CPE now registers with
the network through the AAA server. The entities involved are CPE, authentication function in ASN, and
the AAA server in the CSN.
The CPE now looks for an IP address. An IP address gets assigned to the CPE through DHCP.e.
Up to this point, the CPE has obtained an IP address and establishes a basic logical connection with thef.
network. Now, the CPE registers with the VoIP SIP server by sending out the necessary credentials, which
have been configured through the Provisioning server.
In order to support a VoIP Call, a VoIP application needs to be setup. VoIP application setup involvesg.
provisioning the CPE with VoIP configuration parameters like telephony user accounts, feature activation/
deactivation code for supplementary features, and VoIP application server details from the provisioning
server for establishing a basic call. VoIP application demands guaranteed bandwidth, low latency, and
low jitter in the QOS parameters using the service flow creation. Then, the network begins to allocate
resources and traffic transmission starts.

ASN GATEWAY
CSN GATEWAY
PROVISIONING SERVER
CPE
VOIP SERVER
AAA
CPE
HA
DHCP
ROUTER
PRIVATE
NETWORK
IP CORE
NETWORK
O
MEDIA
GATEWAY
BASE
STATION
CAPC
AAA
DHCP
EMS
NTP
DNS
ROUTER
PRIVATE IP
NETWORK
UTER

Need for Interoperability
Before deployment of a CPE, there is always a need to perform interoperability with the VoIP SIP Server to
identify issues like new feature support, non VoIP IOT issues like configuration issues, customer specific
feature initiation, and management.
InteroperabilityTest Performed
The following VoIP application SIP Servers were tested with WiMAX CPE.
Sylantro — The first interop test was done with Sylantro. A number of issues related to supplementary•
services were fixed.
IMS with Sylantro SIP Server as application server — This interop test was done to figure out the•
incompatibilities specific to IMS environment. A number of issues related to the same were fixed as a
part of this exercise.
Anatel — This is regulatory compliance lab (http://www.anatel.gov.br) in the Brazilian market for ensuring•
ETSI standard compliance. The Interop test on CPE was done as per ETSI TS 102 027-2 to procure a
quality certificate for deploying in the Brazilian market.
Carpo —This IOT was performed with the Carpo SIP server. A number of customer-specific requirements•
were implemented.
Nortel Softswitch — This IOT was performed with Nortel softswitch. A number of issues related•
to implementation incompatibility were fixed. Some customer-specific requirements were also
implemented.
Interoperability Issues
We can broadly classify the interoperability issues into four major categories.
RFC Compliance —These issues arise when the CPE or the SIP server implementations are not compliant1.
with the supported RFCs.
Customer Specific Requirements — This category comprises issues pertaining to features supported2.
by CPE that need to be modified/added (which may include supporting new RFCs/drafts) as per the
customer’s need.
Implementation Incompatibility —These issues arise when the CPE and the server have implementations3.
that are compliant with RFCs but do not inter-operate. This can be attributed to the fact that the RFCs/
drafts leave certain aspects open to implementation which may differ.
Configuration —These issues arise when the CPE is deployed in the customer location and the parameter4.
values related to the CPE and server are not set appropriately.
An analysis of CPE Interop test issues shows that the majority of the issues (85%) fall under the category (2),
category (3), and category (4).

IOT Analysis Strategy
The common tools used for analysis and resolving IOT issues are listed below.
Ethereal was used as capturing and analysis tool for debugging IOT issues.•
The Sip scenario tool was used for deriving sip call flows from the ethereal packet capture for debugging•
supplementary call feature issues.
IOT issues with the Sylantro Server
Sylantro had many customer-specific requirements issues as server processed the supplementary call features
based on new drafts. The feature initiation of the call features were different with respect to CPE.
IOT issues with IMS
There were uncertainties in identifying / troubleshooting issues because IMS testing was carried out•
through a remote lab without proper technical support.Testing and validation of these IMS related issues
therefore required additional effort.
Many configuration issues were faced, as VoIP call flows/parameter values were not consistent across•
normal SIP Server and IMS.
There were many issues related to authentication mechanism, as there is need to support different•
authentication headers in the IMS.

IOT issues with Anatel Server
Verification of IOT issues with Anatel increased the cycle time, as the necessary sip compliance tool•
(INET Spectra-2) was not available due to budgeting constraints. INET Spectra-2 is a sip compliance/
performance tool which is used to generate test cases from the script.
The sipp tool was used as an alternate tool to execute some of the sip compliance tests.•
IOT issues with Carpo Server
The root cause of the IOT issues with Carpo Server took more time, due to an inconsistency in the version of
the server tested and the unavailability of VoIP telephony accounts and technical point of contact.
IOT issues with Nortel Softswitch
IOT with Nortel Softswitch was the longest; many new call features, which were based on new RFCs, had•
to be supported, and the delivery of these features evolved at different phases.
Implementation of the features took time to resolve technical clarifications, which required multiple•
follow-ups with the customer.
Many issues were faced due to sharing of the VoIP test accounts and unstable VoIP server configuration.•
Most of the time was spent in debugging issues because of test setup instability.
Please refer Analysis section for a detailed description of the issues encountered during IOTs.

Interoperability Proposed Guidelines
There are always some challenges involved when performing an interoperability test with any commercial VoIP
application SIP Server. We have conducted a detailed analysis of the issues faced during the different IOTs.
The guidelines below can be followed to meet some of these challenges more effectively.
There should be a formal IOT agreement in place with theVoIP Server vendor, so that all required technical1.
documentation will be available for performing IOT. If a formal agreement is not in place, guidelines 2, 3,
and 4 should be followed immediately to identify and resolve non-technical issues, such as requirement
clarification, resource allocation, and slippage in schedule.
The Marketing team should initiate the IOT process at an early stage, before the product is rolled out in2.
a particular market.
Stable and dedicated VoIP user accounts should be in place before the IOT process begins.3.
Proper technical support contact should be made available from the customer and SIP server vendor for4.
technical clarifications.
The team performing the IOT should be well versed with the SIP RFC (RFC 3261) and the RFCs/drafts5.
associated with different supplementary features. This helps with the quick analysis and resolution of
issues. The team performing the IOT should have a good understanding of the VoIP application on the
product. This is because majority of the IOT issues relate to supplementary features supported by the
application, and this knowledge helps in analyzing issues and suggesting solutions.
Protocol analyzer tools (e.g. INET Spectra-2) can be used to avoid repetitive protocol testing for conformance6.
for each customer. Digital speech analyzer tools (e.g. Multi DSLA from Malden) can be used to benchmark
voice quality of the CPE. These tools could be beneficial for both development and test teams.
Experience in conducting IOT is also a major advantage when it comes to understanding the initiation,7.
control, and implementation of different call features.
Conclusion
In our paper, we have presented an overview of CPE VoIP Interop experience with different VoIP application
servers. We have mentioned different categories of IOT issues faced and the guidelines that can be followed
for Interworking.

Acronyms
AAA Authentication Authorization Accounting
ASN Access Service Network
CAPC Carrier Access Point Controller
CPE Customer Premises Equipment
CSN Connectivity Service Network
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
DSLA Digital Speech Level Analyser
EMS Elementary management system
ERTPS Extended real-time polling service
ETSI European Telecommunications Standards Institute
FQDN Fully qualified domain name
HA Home Agent
IETF Internet Engineering Task Force
IMS IP Multimedia Subsystem
INET International Networking for Educational Transformation
IOT Interoperability Test
IP Internet Protocol
NA Not Applicable
NTP Network Time Protocol
RFC Request for Comments
SBC Session Border Controller
SIP Session initiation protocol
TS Technical Specification
URI Uniform resource identifier
VoIP Voice over IP
Analysis of IOT Issues
Server: Sylantro
Issue 1: 3-way Conference Feature is not working.
Analysis: CPE has to initiate the conference feature through network based conference server. Network
based conference server does media mixing of the three parties of the conference call.CPE has to send an
INVITE to the Conference Server for initiating the conference.
Conclusion: Since CPE needs to support network conference feature based on the new draft, this issue is
classified as customer specific requirement.
Issue 2: Consult Call Transfer is not working.
Analysis: CPE had to send the REPLACES header in the INVITE message while sending to the third party,
even though the other end user did not include the REPLACES parameter in the supported header.
Conclusion: Sending the REPLACES header was customized to suit the customer’s need to make consult
transfer work, so this issue is classifed as customer specific requirement.
Issue 3: Subscribe for an event after time-out.
Analysis: CPE needed to send SUBSCRIBE immediately after the specified telephony account was registered
to the server, but it was then modified to send SUBSCRIBE after the expires timer interval, as specified in the
202, accepted response from the server to the SUBSCRIBE request sent earlier.
Conclusion: CPE has to resend the subscribe after periodic “expires” interval as specified in RFC , this issue
has been categorized as RFC Compliance.

Server: IMS ( Sylantro Server + IMS )
Issue 4: Network De-registration.
Analysis: CPE needs to send a SUBSCRIBE message to the IMS with the “reg” event to receive notification
about the registration status of its account. Based on the notification status, CPE will take appropriate actions
like re-registering with the IMS if it was deregistered by the IMS Core.
Conclusion: Since CPE had to comply with new RFC 3680 to inter-operate with the IMS, this issue is classified
as a customer specific-requirement.
Issue 5: Configure route in the CPE for sending to intermediate SBC instead of a VoIP server.
Analysis: CPE needs to be configured to send SIP messages to intermediate FQDNs like SBC instead of the
VoIP Server. An extra header, ROUTE, was added to include the address-of-record of the destination where
the message needs to be sent.
Conclusion: Since the CPE had to customize to suit the requirements of the end user to configure the
destination FQDN other than VoIP Server domain for sending the message, this issue is classified as a
customer-specific requirement.
Issue 6: Authenticating SIP methods.
Analysis: CPE had to authenticate the SIP methods using www-authenticate header in 401, UNAUTHORIZED
for REGISTER message and proxy-authenticate header in 407, and UNAUTHORIZED for other SIP methods like
INVITE, PRACK, REFER, SUBSCRIBE, and BYE.
Conclusion: Since this was considered an enhancement to authenticate with most of the SIP servers, it is
categorized as Implementation incompatibility.
Server: Anatel
Issue 7: On-hook duration of the CPE is too long.
Analysis: After the voice call was connected, if one of the party hung up, the time taken to disconnect the
remote CPE was not configurable.The on-hook detection was configured to be flexible from 400ms – 2000ms,
to ensure provisionable call disconnection.
Conclusion: Since this solution was given to inter-operate with the SIP server, this issue is classified as a
customer-specific requirement.
Issue 8: The CPE is not RFC compliant.
Analysis: To comply with RFC compliance requirements:
Ensure the CPE, on the receipt of an INVITE request including FROM header without tag, sends a Success•
(200OK) or a provisional (101-199) response including a FROM header without tag. RFC 3261 [1] section
12.1.1
Ensure the CPE establishes a call on receipt of in 2XX, a not acceptable session description, and sends•
an ACK request immediately followed by a BYE request.
Ensure the CPE, having sent an INVITE, sends a Request Pending (491 Request Pending) response on•
receipt of a re-INVITE on this dialog. RFC 3261 [1] section 14.2.
Ensure the CPE, on receipt of a request including a non-supported Method, sends a Method not allowed•
(405 Method Not Allowed) response, including an Allow header that lists the set of method supported.
Ensure the CPE, on receipt of an INVITE request including a message body with a Content-Disposition•
header not set to session value, includes in its first 2xx response an initial offer session description. RFC
3261 [1] sections 13.2.1 and 13.3.1.
Ensure the CPE, on receipt of an INVITE request including escaped characters in the SIP-URI of the•
Contact header, sends a Success (200 OK) response preceded optionally by informational (1XX) response.
RFC 3261 [1] section 19.1.1.
Ensure that the IUT, having already answered to a BYE request,on receipt of a BYE, repeats its last•
response request before timer J fires. Include a Via header set with a different branch parameter, but with
the Request-URI, To tag, From tag,Call-ID, and CSeq identical as in the first BYE request, .
Conclusion: Since this solution was provided to comply with RFC standard for three of the above issues,
this issue is categorized as RFC compliance. The other three issues occured because of some test tool
configuration issues.
Server: Carpo
Issue 9: The CPE is not able to cancel the dialed VoIP call.
Analysis: Calls from the CPE were not able to disconnect before connecting to the terminating end user,
because of missing optional parmater ”Display-name” in the CANCEL SIP message.
Conclusion: Since the following solution was provided to suit the requirements of the server to ensure the
cancellation of the VoIP call, this issue is categorized as customer-specific requirement.

Issue 10: The CPE is not able to register an alphanumeric user with the VoIP server.
Analysis: TheCPE had to send the alphanumeric characters in the SIP-USER part of the FROM header in the
SIP message.
Conclusion: Since the following solution was provided to suit the requirements of the server to ensure a
successful VoIP call, this issue is classified as a customer-specific requirement.
Issue 11: Call transfer is not working.
Analysis: Upon receiving the incoming REFER request from the server, the CPE had to respond with 202
accepted, followed by a NOTIFY of the event, and then send INVITE to theThird party to successfully process
the call transfer according to RFC 3515.
Conclusion: Since providing the following compliance solution, the state machine handling of the incoming
REFER from the client side as per RFC 3515, and matching the requirement of the server, this issue is
classfied as a customer-specific requirement.
Server: Nortel
Issue 12: The CPE is not able to send the character # as %23 in the invite message.
Analysis: The CPE has to process the character ‘#’ as an escaping character ‘%23’ and need to process the
digits followed by ‘#’ as per RFC 2327 .
Conclusion: Since this solution was provided to comply with RFC 2327 to suit the requirements of the server,
this issue is classified as a customer-specific requirement.
Issue 13: Call hold feature is not working.
Analysis: After establishing a VoIP call with a second party, the CPE user has to dial hook-flash, followed by
a feature code, and a special dial tone needs to be played followed by dialing the digits of the third party to
connect to the third party.To swap back to the second party, the CPE user needs to dial hook-flash followed by
the feature code. The same procedure needs to be repeated to connect back to the third party, and so on.
Conclusion: Since the following solution was provided to suit the requirements of the server, this issue is
classified as a customer-specific requirement.
Issue 14: A call transfer should be enabled without dialing a feature code.
Analysis: The CPE has to enable the blind transfer and consult call transfer without dialing feature codes so
as to distinguish between them or other supplementary call features.
classified as customer-specific requirement.
Issue 15: Support a configurable message waiting tone.
Analysis: The CPE has to configure a message waiting tone to confirm the message waiting feature after it
is enabled.
Issue 16: Support configurable hook-flash tone.
Analysis: The CPE has to configure a hook-flash tone, similar to a varied type of a dial tone, to confirm the
activation of a supplementary call feature .
Issue 17: Support 10 distinctive ring tones.
Analysis: The CPE has to configure ten distinctive ring tones to confirm to the receiver that the present call
is due to the activation of a specific supplementary call feature.
Issue 18: The CPE is not processing INVITE without SDP.
Analysis: CPE has to process an INVITE without SDP by filling its list of supported codecs in the SDP body
of the 200 ok response.
Conclusion: This is an RFC Compliance issue with RFC 3261.
Issue 19: Support configurable call-waiting disable tone.
Analysis: CPE has to configure a call waiting disable tone to confirm the disabling of the call-waiitng feature.

Server: Not Applicable
Issue 20: Audio quality during the voice call is poor.
Analysis: CPE telephony port parameters, such as Ring type, Ring DC offset, Ring voltage, Rx, and Tx off-
hook digital gain, need to configured to appropriate values.
Conclusion: This configuration issue is related to voice quality.
Issue 21: Though the CPE ports are registered, users are unable to make VoIP calls.
Analysis: At the AAA server side, the WiMAX-Service-Flows parameter should have authorized VoIP service
flows in addition to the best effort data. At the EMS side, the service flow parametrs like Tolerated Jitter and
maximum latency should have been configured with appropriate values.
Conclusion: This configuration issue is related to service-flow classes.

Appendix: IOT Issue List
SIP Server Issue List Category
Sylantro (Initial IOT) Network-based, 3-way conferencing:1.
supports a new way of network-based
conferencing based on new draft.
Customer Specific Requirement
Consult Call Transfer in different scenario:2.
always send the REPLACES header for a
transfer to work.
Subscription after a time-out: a3.
resubscribe was sent based on the 200
ok response interval, which was initially
sent periodically, irrespective of 200 ok’s
interval.
RFC Compliance
IMS (Sylantro Server
+ IMS) IOT
Network de-registration1. Customer Specific Requirement
Configurable destination FQDN other2.
than domain for sending the SIP
Messages.
Authenticating SIP methods: (PRACK,3.
INVITE, SUBSCRIBE, REFER): handlling
401 was used for authentication in normal
Sylantro, whereas 407 handling for
authentication was missing.
Implementation incompatibility
Anatel Provisioning on-hook duration: new1.
provisioning tags have been added for
customizing on- hook duration.
Validate RFC Compliance for the CPE:2.
some RFC compliance tests failed
when they were tested with the SIP
compliance tool.
RFC Compliance ( Tested with
tool for sip compliance)
Carpo Cancel only when the FROM header has1.
a display name in the CANCEL message.
Alphanumeric characters in the FROM2.
header other than the TEL-URL
Call Transfer by handling incoming REFER3.
in the Client side.
RFC Compliance
Nortel # character needs to be escaped (RFC1.
2327).
Call Hold feature: The Call Hold2.
feature controlled by CPE was newly
implemented.
Implementation incompatibility
The Call Transfer feature should be3.
enabled without dialing a feature code.
Support configurable message waiting4.
tone.
Support configurable hookflash tone.5. Customer Specific Requirement
Support 10 distinctive ring tones.6. Customer Specific Requirement
Processing INVITE without SDP.7. RFC Compliance
Support configurable Call-Waiting Disable8.
tone.
NA Voice quality during the call.1. Configuration
NA Unable to make a call.1. Configuration

Motorola, Inc. www.motorola.com
MOTOROLA and the Stylized M Logo are registered in the U.S. Patent and Trademark Ofﬁce. All other product or service names are the property of their respective
owners.
© Motorola, Inc. 2008
557980-001-a 09/08

WiMAX_CPE_VoIP

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to WiMAX_CPE_VoIP

Similar to WiMAX_CPE_VoIP (20)

WiMAX_CPE_VoIP