Asha VoIP v1 0 Implementation Specifications v1 0 En

8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En

1/31

Nokia Asha VoIP v1.0Implementation Specifications

Document created on 22 October 2013

Version 1.0


2/31

Nokia Asha VoIP v1.0 Implementation Specifications 2

Table of contents

1. Introduction 3

2. Features 42.1 Basic call 4

2.1.1 Offer/Answer 62.1.2 Codec payloads 72.1.3 Comfort noise 112.1.4 Media QoS marking 122.1.5 Signaling QoS 122.1.6 DTMF 13

2.2 Secure call 132.3 Call forwarding 142.4 Call transfer 152.5 CLIP 162.6 CLIR 162.7 Message waiting indicator (MWI) 172.8 NAT/FW traversal 18

2.8.1 STUN 182.8.2 Symmetric signalling 182.8.3 Symmetric media 192.8.4 Open ports for RTP/RTCP traffic 192.8.5 NAT binding keep alive 19

2.9 Hold 202.10 Call waiting 21

2.11 Emergency call 212.12 RTCP Extended Reports for VoIP metrics 212.13 Phone management 23

3. Terms and abbreviations 24

4. References 28

Change history

22 October 2013 Version 1.0 Initial document release


3/31


1. IntroductionThis document describes how the implementation of Nokia Asha Voice over IP (VoIP) v1.0 fulfils the InternetEngineering Task Force (IETF), 3rd Generation Partnership Project (3GPP), International Telecommunication Union

(ITU), Open Mobile Alliance (OMA), and other specifications related to the provision of VoIP.

Note: Radio-related specifications, such as the Institute of Electrical and Electronics Engineers, Inc. (IEEE)

specifications, fall outside the scope of this document.


4/31


2. FeaturesThis section provides information on the specifications that each functional area of Nokia Asha Voice over IP(VoIP) v1.0 implements. Within each section the specifications are listed in the section Related specifications

while notes on the implementation of the specifications are provided in the section Implementation notes.

2.1 Basic callRelated specifications

RFC 2617 HTTP Authentication: Basic and Digest Access Authentication[13] RFC 3261 SIP: Session Initiation Protocol[15] RFC 3262 Reliability of Provisional Responses in the Session Initiation Protocol (SIP)[19] RFC 3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key

Agreement (AKA)[26]

RFC 3550 RTP: A Transport Protocol for Real-Time Applications[32] RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control[33] RFC 4855 Media Type Registration of RTP Payload Formats[35] RFC 4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences

[24]

RFC 3665 Session Initiation Protocol (SIP) Basic Call Flow Examples[38] RFC 3824 Using E.164 numbers with the Session Initiation Protocol (SIP)[39]Implementation notes

Support is provided for: the creation of a new request after responses 401 and 407. (Section 8.1.3.5, RFC 3261.) Re-INVITE

once after receipt of response 491 is supported. (Section 14.2, RFC 3261.)

INVITE in and outside a dialog. CANCEL is supported outside a dialog. ACK, BYE, NOTIFY, REFER, PRACK,and UPDATE are supported inside an existing dialog. The phone responses to incoming unsupported

messages with responses 501, Not Implemented, or 405, Method Not Allowed.

IPv4 and IPv6 in signalling. E.164 numbers in SIP URI format si p: @,for example,

si p: 1234567@domai n. com, that is the parameter user : phoneis not included. (RFC 3824)


5/31


HTTP Digest and Digest AKA as SIP authentication method. Support is not provides for:

Session establishment through two proxies. (Sections 3.2, RFC 3665.)

Successful session with proxy failure. (Sections 3.4, RFC 3665.) Session through a SIP ALG. (Sections 3.5, RFC 3665.)


6/31


2.1.1 Offer/AnswerRelated specifications

RFC 4566 SDP: Session Description Protocol[11] RFC 3264 An Offer/Answer Model with the Session Description Protocol (SDP)[23] RFC 4855 Media Type Registration of RTP Payload Formats[35] RFC 4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences

[24]

RFC 3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)[43] RFC 3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth

[56]

3GPP 26.114 3rd Generation Partnership Project; Technical Specification Group Services and SystemAspects; IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction (Release 8)

[57]

Implementation notes

Early Media is supported. Reference to RFC 3960 is made in order to identify a specification describing thegeneration of a local ringing tone, should Early Media not be available.

Bandwidth modifiers are supported. Implementation of the bandwidth modifiers (b=AS:, b=RR: and b=RS:) isaccording to RFC 3556 and 3GPP 26.114.

The implementation is in accordance with RFC 3264 with the following exceptions: A port number of zero is used to reject offered media for MT sessions. (Section 5.1, RFC 3264.) Multicast streams are not supported. Streams are marked as sendonl ywhen generating an offer for HOLD inside a session and r ecvonl y

when generating an ANSWER to a HOLD offer. Streams are marked as r ecvonl yin ANSWER when

i nact i veis received in an offer. Attribute sendr ecvis used when resuming from HOLD (in offer and

ANSWER) only. (Section 6.1, RFC 3264).

Every ANSWER to any offer contains the most preferred supported codec only. (Section 6.1, RFC 3264.) Packetisation interval is supported with pt i meand maxpt i meattributes. (Section 6.1, RFC 3264.)

One media stream (audio) only is supported. (Chapter 8, RFC 3264.)


7/31


Changing the port number during a session is not supported in the MO (Mobile Originated) direction,but is supported in the MT (Mobile Terminated) direction. In other words, a new offer with a different

port number is not supported, but an arrived offer from another source with a changed port number is

supported. (Section 8.3.1, RFC 3264.)

Changing the transport of a stream is not supported. (Section 8.3.1, RFC 3264.) Changing the media type during the session is not supported. (Section 8.3.3, RFC 3264.) Receiving audio with every codec presented in sent offer is supported.

2.1.2 Codec payloadsRelated specifications

AMR-NB 3GPP TS 26.090 AMR Speech Codec; Transcoding Functions[1] RFC 4867, RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive

Multi-Rate Wideband (AMR-WB) Audio Codecs[25]

AMR-WB 3GPP TS 26.190 Wideband (AMR-WB) speech codec; Transcoding functions[51] RFC 4867, RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive


G.711 (PCMA/PCMU) ITU-T G.711 Appendix I[5] ITU-T G.711 Appendix II[6] RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control[33] RFC 4855 Media Type Registration of RTP Payload Formats[35] RFC 4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video

Conferences[24]


8/31


G.729 ITU-T G.729[8]

ITU-T G.729 Annex B[9]

RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control[33] RFC 4855 Media Type Registration of RTP Payload Formats[35] RFC 4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video

Conferences[24]

G.726 ITU-T G.726[7] RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control[33] ITU-T I.366.2 AAL type 2 service specific convergence sublayer for trunking[34] RFC 4855 Media Type Registration of RTP Payload Formats[35] RFC 4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video

Conferences[24]

iLBC RFC 3951 Internet Low Bit Rate Codec (iLBC)[48] RFC 3952 RTP Payload Format for iLBC Speech[49]

GSM-FR 3GPP TS 46.010, Full rate speech; Transcoding[52] RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control[33]

GSM-EFR

3GPP TS 46.060, Enhanced Full Rate (EFR) speech transcoding[53]

RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control[33]


9/31



AMR-NB and AMR-WB: Payload format does not support UEP or UED. (Section 3.6.1, RFC 4867.) This means that frame CRCs

are not supported also. (Section 4.4.2, RFC 4867.)

RTP Packets containing NO_DATA frames only are not sent. NO_DATA frame blocks that containNO_DATA at the end of an RTP packet are sent. (Section 4.3.2, RFC 4867.) The implementation does

support receiving packets consisting of NO_DATA frame blocks only (for example, between

SID_UPDATEs).

Payload format supports single or double redundancy (AMR FEC) only. (Section 3.7.1, RFC 4867.)

The following MIME parameters are supported and can be negotiated: octet-align, mode-set, mode-change-period, mode-change-neighbor,ptime, maxptime, and max-red.

The following MIME parameters are neither supported nor accepted in negotiation: crc, robust-sorting,interleaving, and mode-change-capability.

The following MIME parameters have a restricted set of values that can be negotiated: channels; singlechannel payload is supported (channel s=1) and used by default if omitted in negotiation, and max-red;

seeTable 1 for the restrictions.

SDP offer FEC defined in the provisioned VoIP settingsFEC not defined in the provisioned VoIP

settings

Mobile

Originated

max-redisptimemultiplied by FEC.[54] defines

the highest value for max-redas 220. Ifptime

multiplied by FECexceeds 220, FECwill be set to 0

for that codec. If ptimeis not defined in the

settings, max-redis given the default ptimevalue

of 20.

max-redis not advertised in the offer.


10/31


SDP offer FEC defined in the provisioned VoIP settingsFEC not defined in the provisioned VoIP

settings

Mobile

Terminated

If the received values for max-redand ptimearethe same and the corresponding value has been

defined for ptimein the settings, max-redis given

the received value in the SDP answer.

If the received value ofptimedoes not correspond

with the received value of max-redor the value of

ptimein the settings, max-redis set to 0in the

SDP answer.

Ifptimeis not present in the received offer, max-

redis given the default ptimevalue of 20in the

SDP answer.

If max-redis present in the received offer, it is set

to 0in the SDP answer. If max-redis not present

in the offer, it will not be present in the answer.

Table 1: Restrictions that apply to the handling of the max-red parameter are listed.

G.711: DTX is supported with Generic Comfort Noise (CN) on the sender side. (Section 4.1, RFC 3551.) G.711 payload format are supported. (Section 4.5.14, RFC 3551.) The following MIME parameters are supported and can be negotiated:ptime, multiples of 10ms are

supported, and maxptime.

G.729: DTX is supported with G.729 Annex B on the sender side. (Section 4.1, RFC 3551.) G.729 payload formats G.729, G.729A, and G.729 Annex B are support. (Section 4.5.6, RFC 3551).

Other G.729 versions are not supported.

The following MIME parameters are supported and can be negotiated:ptime;multiples of 10ms aresupported, maxptime, and annexb, value yesis implied if this parameter is omitted in negotiation.


11/31


G.726: DTX is supported with Generic Comfort Noise (CN) on sender side. (Section 4.1, RFC 3551.)

Support for G.726 payload format as specified in Annex E of ITU-T I.366.2 or Section 4.5.4 of RFC 3551depends on the provisioned VoIP settings, which are defined in the

http://www.forum.nokia.com/info/sw.nokia.com/id/bab1e52e-3c1b-46f8-9b38-

da9db782da4e/Asha_VoIP_v1_0_Implementation_Specifications.html.

All bitrates are supported, MIME subtypes: G726-16, G726-24, G726-32, and G726-40. The following MIME parameters are supported and can be negotiated:ptime, multiples of 10ms are

supported, and maxptime.

iLBC: DTX is supported. (Section 4.1, RFC 3551.) iLBC payload format is supported (RFC 3952). The following MIME parameters are supported and can be negotiated:ptime, maxptime, and mode, the

30ms mode (mode=30) is used by default if omitted in negotiation.

Payload types: Codecs having dynamic payload types will be numbered in ascending order starting from 96 (that is 96,

97, 98 etc.) according to the order of codecs in the phones provisioned VoIP settings, with the

exception that the Telephone-event is given the last value.

2.1.3 Comfort noiseRelated specifications

RFC 3389 RTP Payload for Comfort Noise (CN)[29] RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control[33] RFC 4867 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive

http://www.forum.nokia.com/info/sw.nokia.com/id/bab1e52e-3c1b-46f8-9b38-da9db782da4e/Asha_VoIP_v1_0_Implementation_Specifications.htmlhttp://www.forum.nokia.com/info/sw.nokia.com/id/bab1e52e-3c1b-46f8-9b38-da9db782da4e/Asha_VoIP_v1_0_Implementation_Specifications.htmlhttp://www.forum.nokia.com/info/sw.nokia.com/id/bab1e52e-3c1b-46f8-9b38-da9db782da4e/Asha_VoIP_v1_0_Implementation_Specifications.htmlhttp://www.forum.nokia.com/info/sw.nokia.com/id/bab1e52e-3c1b-46f8-9b38-da9db782da4e/Asha_VoIP_v1_0_Implementation_Specifications.htmlhttp://www.forum.nokia.com/info/sw.nokia.com/id/bab1e52e-3c1b-46f8-9b38-da9db782da4e/Asha_VoIP_v1_0_Implementation_Specifications.html


12/31



Generic comfort noise support with G.711 (PCMA & PCMU) and G.726 codecs is provided, (RFC 3389.) Generic comfort noise is supported with iLBC. (RFC 3389.) Update interval for generic CN depends on the codec used. The CN update occurs when the encoder detects

significant changes in the background noise resulting in the implementation generating and sending an

updated CN RTP packet.

Generic comfort noise usage with AMR is not supported, as the AMR codec itself contains a method forcomfort noise/silence suppression that can be signalled inband if VAD is enabled.

Generic CN usage with G.729 is not supported, instead G.729 Annex B is used. (RFC 3551.)

2.1.4 Media QoS markingRelated specifications

RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers[50]Implementation notes

The code point 101110 (46 dec) is used as the default code point.

2.1.5 Signaling QoSRelated specifications

RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers[50]Implementation notes

The code point 101000 (40 dec) is used as the default code point.


13/31


2.1.6 DTMFRelated specifications

RFC 4733 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals[14]Implementation notes

Support is provided for: Out-of-band DTMF sending. (RFC 4733) RTP payload format for named telephone events (Chapter 2, RFC 4733) with full support for specified

DTMF events (Section 3.2, RFC 4733).

In-band DTMF playback.

Support is not provide for: RTP Payload Format for Telephony Tones. (Chapter 4, RFC 4733.) Out-of-band DTMF playback at the receiving end. In-band DTMF sending.

2.2 Secure callRelated specifications

RFC 3261 SIP: Session Initiation Protocol[15] draft-ietf-sip-sips-06.txt The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)[16] RFC 3711 The Secure Real-time Transport Protocol (SRTP)[17] RFC 4568 Session Description Protocol (SDP) Security Descriptions for Media Streams[18] RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers[20] RFC 2782 A DNS RR for specifying the location of services (DNS SRV)[21] RFC 2915 The Naming Authority Pointer (NAPTR) DNS Resource Record[22]Implementation notes

Supports SIPS scheme only in all headers TLS transport URI parameter is not supported (as defined in draft-ietf-sip-sips-06.txt) Re-direction from secure to unsecure is not allowed. No user query is made in such a case. Security preconditions are not supported.


14/31


Supports is provided for the following fallback logic with MO calls: If the destination address is a SIPS URI: A secure call is attempted without fallback.

If secure call is mandated in the provisioned VoIP settings: A secure call is attempted without fallback.

If secure call is preferred in the provisioned VoIP settings: A secure call is attempted first. If it fails, afallback to non-secure call is attempted.

If non-secure call is preferred in the provisioned VoIP settings: A non-secure call is attempted first. Ifthe network or the remote endpoint rejects the call attempt with a 480 (Temporarily Unavailable)

response with a Warning header with warn-code 381 SIPS Required, a fallback to secure call is

attempted.

2.3 Call forwardingRelated specifications

draft-ietf-sipping-service-examples-12.txt Session Initiation Protocol Service Examples[2] RFC 3261 SIP: Session Initiation Protocol[15] ETSI TS 183 004 PSTN/ISDN simulation services: Communication Diversion (CDIV); Protocol specification

V1.1.1[44]


Section 21.1.3 of RFC 3261 is supported by recognising the response 181, Call Is Being Forwarded, answer. Section 21.3.2 of RFC 3261 is supported by recognising the response 301, Moved Permanently. Section 21.3.3 of RFC 3261 is supported by recognising the response 302, Moved Temporarily. Response

300 is handled as an error, while responses 301 and 302 are redirected to the requested URI.

Response 302, Moved Temporarily is used in the MT forwarding case.


15/31


2.4 Call transferRelated specifications

draft-ietf-sipping-service-examples-12.txt Session Initiation Protocol Service Examples[2] RFC 3515 The Session Initiation Protocol (SIP) Refer Method[31] RFC 3891 The Session Initiation Protocol (SIP) "Replaces" Header[41] RFC 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism[42] ETSI TS 183 029 PSTN/ISDN simulation services: Explicit Communication Transfer (ECT); Protocol

specification V1.1.1[45]


Support is provided for: Receiving attended call transfer. (Section 2.5, draft-ietf-sipping-service-examples-12.txt.) Receiving unattended call transfer from remote party. (Section 2.4, draft-ietf-sipping-service-

examples-12.txt.)

Rejected transfer by sending response 503, Service Unavailable to REFER. Failed transfer by sending NOTIFY with response 503 Service Unavailable. No other failing NOTIFY

responses are sent.

Support is not provided for: REFER arriving in a new dialog. Initiating attended call transfer. (Section 2.5, draft-ietf-sipping-service-examples-12.txt.) Initiating unattended call transfer. (Section 2.4, draft-ietf-sipping-service-examples-12.txt.) Multiple REFER requests in a dialog. (Section 2.4.6, RFC 3515.)


16/31


2.5 CLIPRelated specifications

RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP)[27] RFC 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted

Networks[28]


In the MO direction, when CLIP is on (that is, when CLIR is off), the Privacyheader is omitted. The network might support or add support for the P-Asserted-Identity header. (Section 9.1, RFC 3325.) If the

header is present, remote identity is read from this header rather than from the Fromheader.

2.6 CLIRRelated specifications

RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP)[27] RFC 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted

Networks[28]


In the MO direction, support is provided for: Privacyheader. Note that the header value is i dwhen CLIR is on. (Section 9.3, RFC 3325 and Section

4.2, RFC 3323.)

Fromheader, when CLIR is on, is set as Anonymous . (Section4.1.1.3, RFC 3323.)

In the MT direction, the Fromheader is checked to determine if an anonymous call is being made.


17/31


2.7 Message waiting indicator (MWI)Related specifications

RFC 3842 A Message Summary and Message Waiting Indication Event Package for the Session InitiationProtocol (SIP)[40]


Support is provided for: MWI to the user with audible and visible information. After the user interaction, the MWI is discarded

without being stored in the message inbox. (Chapter 2, RFC 3842).

Boolean message waiting notification (Message-Waiting: Yes) that does not contain a messagesummary. (Sections 3.5, RFC 3842).

Following parameters are parsed from the NOTIFY content and shown on the UI (Sections 3.5 and 4.1, RFC3842):

Message-Waiting. Voice-Messages. New messages.

Support is not provided for MWI indication NOTIFY without SUBSCRIBE. Following parameters are not parsed from NOTIFY content (Sections 3.5 and 4.1, RFC 3842):

Fax-Messages. Message-Account. From. Old messages.

Subject.

Date. Priority. Message-ID. To.


18/31


2.8 NAT/FW traversal2.8.1 STUNRelated specifications

RFC 3489 STUN: Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators(NATs)[30]


Support is not provided for Binding Acquisition (Section 10.3, RFC 3489) except for STUN bindingrequest/response and STUN binding refreshing (keep alive).

Support is not provided for shared secret request/response. (Section 8.2, RFC 3489.)

2.8.2 Symmetric signallingRelated specifications

RFC 3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing[36]Implementation notes

Public IP address and port are discovered using STUN when SIP registration is undertaken over UDP and STUNis enabled in the provisioned VoIP settings. This is used to check whether the public address seen by the SIP

server differs from the address received in the network link setup.

Support is provided for the rport parameter in the Viaheader field. (RFC 3581) This enables a client torequest that the server sends the response back to the requests source IP address and port.

When SIP registration is undertaken over TCP (or over UDP when STUN is disabled in the provisioned VoIPsettings), the Viaheader (from the first response to REGISTER) is checked for the r ecei vedand rport

parameters. These parameters advertise the public IP address and port as seen by the SIP server. If they are

different from the local addresses received in the network link setup, there are NATs on the route. In this

case the public IP address and port are obtained from the first response to REGISTER (when rport is used).

The obtained address is then used in the next registration / re-registration in the Contact header.

Default port number 5060 is used for SIP signalling if not otherwise discovered. For the symmetric SIP signalling, SIP requests and responses are received and sent from the same address

and port.


19/31


2.8.3 Symmetric mediaRelated specifications

RFC 4961 Symmetric RTP / RTP Control Protocol (RTCP)[3]Implementation notes

RFC 4961 is supported in full. Multiplexing RTP data and control packets on a single port are not supported. (draft-ietf-avt-rtp-and-rtcp-

mux-07.txt[4].)

2.8.4 Open ports for RTP/RTCP trafficRelated specifications

RFC 3605 Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)[37] RFC 3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)[43]Implementation notes

Only separated RTP and RTCP ports are supported. Support is provided for different IP addresses for RTCP and RTP as follows:.

Local ports for RTP and RTCP can be mapped (by a NAT) to different external IP addresses. These areobtained from STUN Binding Responses.

Remote IP addresses for RTP and RTCP can be different. These are obtained from a remote SDP.

2.8.5 NAT binding keep aliveRelated specifications

None.


Firewall keep alive for uplink stream is started in the MO sessions every time a provisional answer with SDPcontent is received and stopped when response 200, OK, is received. Keep alive is used when session is on

hold also. In both situations, RTP dummy packets are sent using a payload encoded in the audio codec that

matches the signalling on the RTP dummy packets .

STUN protocol is used for obtaining the corresponding public IP address and port for the private address andport.


20/31


NAT and/or firewall bindings are kept alive by refreshing them while a session is in a hold state. If the addressof the phone is different from the address returned by the networks STUN server, and the IP address and

port of the outbound proxy (or registrar when there is no outbound proxy) and local STUN server address and

port are not identical:

UDP packets containing CRLFCRLF are sent to the SIP proxy or registrar, when there is no outboundproxy (for keep-alive).

STUN binding request packets are sent to the networks STUN server (for detecting flow failure due toNAT reboot).

When TCP is used, STUN is not used for public address queries. TCP keep-alive (by sending a dummy octetpacket and waiting for an ACK response) is used to find out if the TCP connection has been disconnected.

To keep a media link alive in the MT call setup to account for the possible of Early Media being transmitted,RTP packets are sent with silence information in the payload until 200 packets have been sent and encoding

of the uplink media has started.

2.9 HoldRelated specifications

RFC 3261 SIP: Session Initiation Protocol[12] RFC 3264 An Offer/Answer Model with the Session Description Protocol (SDP)[23]Implementation notes

Support is provided for: Hold. (Section 8.4, RFC 3264.) Both unidirectional and bidirectional hold and resume. Receiving of old-way hold. (Chapter B.5, RFC 2543.)

Support is not provided for multicast streams.


21/31


2.10 Call waitingRelated specifications

RFC 3261 SIP: Session Initiation Protocol[15]Implementation notes

Incoming calls are responded to with SIP message 182, Queued, when the call is in the waiting state becauseanother call is active at the receiving end.

2.11 Emergency callVoIP emergency call is not supported. An emergency call is always made through the cellular network.

2.12 RTCP Extended Reports for VoIP metricsRelated specifications

RFC 3611 RTP Control Protocol Extended Reports (RTCP XR)[55]


22/31



Supported and unsupported metrics of the VoIP metrics report block (Section 4.7, RFC 3611) are presentedinTable 2.

Metrics of VoIP Metrics Report BlockRequirement level for

compliance by RFC 3611

Supported by

implementation

Packet Loss and Discard MetricsLoss rate MUST Yes

discard rate MUST Yes

urst Metricsburst density MUST Yes

Gap density MUST Yes

burst duration MUST Yes

Gap duration MUST Yes

Delay Metricsround trip delay MUST Yes

end system delay SHOULD No

Signal Related Metrics

signal level SHOULD No

noise level SHOULD No

residual echo return loss SHOULD No

Call Quality or Transmission Quality MetricsR factor SHOULD No


23/31


Metrics of VoIP Metrics Report BlockRequirement level for

compliance by RFC 3611

Supported by

implementation

ext. R factor SHOULD No

MOS-LQ SHOULD No

MOS-CQ SHOULD No

Configuration Parameterspacket loss concealment MUST Yes

jitter buffer adaptive MUST Yes

jitter buffer rate MUST Yes

Jitter uffer Parametersjitter buffer nominal delay MUST Yes

jitter buffer maximum delay MUST Yes

jitter buffer absolute maximum delay MUST Yes

Table 2: Supported and unsupported metrics of the VoIP metrics report block are listed.

2.13 Phone managementRelated specifications

OMA Device Management version 1.1.2[46] OMA Client Provisioning version 1.1[47]


Support is provided for: OMA Device Management version 1.1.2. OMA Client Provisioning version 1.1.


24/31


3. Terms and abbreviationsTerm or abbreviation Meaning

3GPP The 3rd Generation Partnership Project

a-law Name of G.711 PCMU algorithm

AKA Authentication and Key Agreement

AMR-NB Adaptive Multi-Rate Narrowband

AMR-WB Adaptive Multi-Rate Wideband

AOR Address-of-record

API Application Programming Interface

CLIP Calling Line Identification Presentation

CLIR Calling Line Identification Restriction

CN Comfort Noise

CP Client Provisioning

CRC Cyclic Redundancy Check

CRLF Formatting control codes Carriage Return (CR) and Line Feed (LF)

CS call Circuit-switched call

DM Device Management

DND Do Not Disturb

DTMF Dual-Tone Multifrequency

DTX Discontinuous Transmission


25/31


Term or abbreviation Meaning

FEC Forward Error Correction

FW Firewall

GSM-EFR GSM Enhanced Full Rate

GSM-FR GSM Full Rate

HTTP Hyper Text Transport Protocol

iLBC Internet Low Bitrate Codec

IEEE The Institute of Electrical and Electronics Engineers, Inc.

IETF The Internet Engineering Task Force

IP Internet Protocol

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

ITU International Telecommunication Union

MaxptimeThe maximum amount of media (in milliseconds) which can be encapsulated in a

payload packet.

MIME Multipurpose Internet Mail Extensions

MO Mobile Originated

MT Mobile Terminated

MWI Message Waiting Indicator

NAT Network Address Translation

OMA Open Mobile Alliance

PCMA Pulse Code Modulation a-law


26/31



PCMU Pulse Code Modulation -law

Ptime

The preferred amount of media (in milliseconds) which is encapsulated in a payload

packet. The actual packetisation interval is usually the same as ptime, but can vary

depending on the usage of VAD and/or DTX.

PHB Per-Hop Behaviour

PS call Packet-switched call

QoS Quality of Service

RFC Request For Comments

RTCP Real-Time Transport Control Protocol

RTCP XR RTCP Extended Reports

RTP Real-Time Transport Protocol

SDP Session Description Protocol

SID Silence Insertion Descriptor

SIP Session Initiation Protocol

STUNSimple Traversal of UDP through NAT; a protocol that allows applications to detect

that network address translation (NAT) is being used.

TCP Transmission Control Protocol

UDP User Datagram Protocol

UED Unequal Error Detection

UEP Unequal Error Protection

UI User Interface

URI Uniform Resource Identifier


27/31



VAD Voice Activity Detection

VoIP Voice over IP

-law Name of G.711 PCMU algorithm


28/31


4. References[1] 3GPP TS 26.090, AMR Speech Codec; Transcoding Functions, available athttp://www.3gpp.org/[2] draft-ietf-sipping-service-examples-12.txt, Session Initiation Protocol Service Examples, available

athttp://www.ietf.org/

[3] RFC 4961, Symmetric RTP / RTP Control Protocol (RTCP), available athttp://www.ietf.org/[4] draft-ietf-avt-rtp-and-rtcp-mux-07.txt, Multiplexing RTP Data and Control Packets on a Single

Port, available athttp://www.ietf.org/

[5] ITU-T G.711 Appendix I, available athttp://www.itu.int[6] ITU-T G.711 Appendix II, available athttp://www.itu.int[7] ITU-T G.726, available athttp://www.itu.int[8] ITU-T G.729, available athttp://www.itu.int[9] ITU-T G.729 Annex B, available athttp://www.itu.int[10] RFC 2198, RTP Payload for Redundant Audio Data, available athttp://www.ietf.org/[11] RFC 4566, SDP: Session Description Protocol, available athttp://www.ietf.org/[12] RFC 3261, SIP: Session Initiation Protocol, available athttp://www.ietf.org/[13] RFC 2617, HTTP Authentication: Basic and Digest Access Authentication, available at

http://www.ietf.org/

[14] RFC 4733, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, available athttp://www.ietf.org/

[15] RFC 3261, SIP: Session Initiation Protocol, available athttp://www.ietf.org/[16] draft-ietf-sip-sips-06.txt, The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP),

available athttp://www.ietf.org/

[17] RFC 3711, The Secure Real-time Transport Protocol (SRTP), available athttp://www.ietf.org/[18] RFC 4568, Session Description Protocol (SDP) Security Descriptions for Media Streams, available

athttp://www.ietf.org/

[19] RFC 3262, Reliability of Provisional Responses in the Session Initiation Protocol (SIP), available athttp://www.ietf.org/

[20] RFC 3263, Session Initiation Protocol (SIP): Locating SIP Servers, available athttp://www.ietf.org/[21] RFC 2782, A DNS RR for specifying the location of services (DNS SRV), available at


[22] RFC 2915, The Naming Authority Pointer (NAPTR) DNS Resource Record, available athttp://www.ietf.org/
http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.itu.int/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.3gpp.org/


29/31


[23] RFC 3264, An Offer/Answer Model with the Session Description Protocol (SDP), available athttp://www.ietf.org/

[24] RFC 4856, Media Type Registration of Payload Formats in the RTP Profile for Audio and VideoConferences, available athttp://www.ietf.org/

[25] RFC 4867, RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) andAdaptive Multi-Rate Wideband (AMR-WB) Audio Codecs, available athttp://www.ietf.org/

[26] RFC 3310, Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and KeyAgreement (AKA), available athttp://www.ietf.org/

[27] RFC 3323, A Privacy Mechanism for the Session Initiation Protocol (SIP), available athttp://www.ietf.org/

[28] RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity withinTrusted Networks, available athttp://www.ietf.org/

[29] RFC 3389, RTP Payload for Comfort Noise (CN), available athttp://www.ietf.org/[30] RFC 3489, STUN: Simple Traversal of User Datagram Protocol (UDP) Through Network Address

Translators (NATs), available athttp://www.ietf.org/

[31] RFC 3515, The Session Initiation Protocol (SIP) Refer Method, available athttp://www.ietf.org/[32] RFC 3550, RTP: A Transport Protocol for Real-Time Applications, available athttp://www.ietf.org/[33] RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control, available at


[34]

ITU-T I.366.2, AAL type 2 service specific convergence sublayer for trunking, available athttp://www.itu.int

[35] RFC 4855, Media Type Registration of RTP Payload Formats, available athttp://www.ietf.org/[36] RFC 3581, An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing,


[37] RFC 3605, Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP),available athttp://www.ietf.org/

[38] RFC 3665, Session Initiation Protocol (SIP) Basic Call Flow Examples, available athttp://www.ietf.org/

[39] RFC 3824, Using E.164 numbers with the Session Initiation Protocol (S IP), available athttp://www.ietf.org/

[40] RFC 3842, A Message Summary and Message Waiting Indication Event Package for the SessionInitiation Protocol (SIP), available athttp://www.ietf.org/

[41] RFC 3891, The Session Initiation Protocol (SIP) "Replaces" Header, available athttp://www.ietf.org/

[42] RFC 3892, The Session Initiation Protocol (SIP) Referred-By Mechanism, available athttp://www.ietf.org/
http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.itu.int/http://www.itu.int/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.itu.int/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/


30/31


[43] RFC 3960, Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP),available athttp://www.ietf.org/

[44] ETSI TS 183 004 PSTN/ISDN simulation services: Communication Diversion (CDIV); Protocolspecification V1.1.1, available athttp://www.etsi.org

[45] ETSI TS 183 029 PSTN/ISDN simulation services: Explicit Communication Transfer (ECT); Protocolspecification V1.1.1, available athttp://www.etsi.org

[46] OMA Device Management v1.1.2, available athttp://www.openmobilealliance.com/[47] OMA Client Provisioning v1.1, available athttp://www.openmobilealliance.com/[48] RFC 3951, Internet Low Bit Rate Codec (iLBC), available athttp://www.ietf.org/[49] RFC 3952 , RTP Payload Format for iLBC Speech, available athttp://www.ietf.org/[50] RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,


[51] 3GPP TS 26.190, Wideband (AMR-WB) speech codec; Transcoding Functions, available athttp://www.3gpp.org/

[52] 3GPP TS 46.010, Full rate speech; Transcoding, available athttp://www.3gpp.org/[53] 3GPP TS 46.060, Enhanced Full Rate (EFR) speech transcoding, available athttp://www.3gpp.org/[54] 3GPP TS 26.114, Media handling and interaction, available athttp://www.3gpp.org/[55] RFC 3611 , RTP Control Protocol Extended Reports (RTCP XR), available athttp://www.ietf.org/[56] RFC 3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP)

Bandwidth, available athttp://www.ietf.org/

[57] 3GPP 26.114 3rd Generation Partnership Project; Technical Specification Group Services andSystem Aspects; IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and

interaction (Release 8) v8.4, available athttp://www.3gpp.org
http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.etsi.org/http://www.etsi.org/http://www.etsi.org/http://www.etsi.org/http://www.etsi.org/http://www.etsi.org/http://www.openmobilealliance.com/http://www.openmobilealliance.com/http://www.openmobilealliance.com/http://www.openmobilealliance.com/http://www.openmobilealliance.com/http://www.openmobilealliance.com/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.ietf.org/http://www.ietf.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.3gpp.org/http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.openmobilealliance.com/http://www.openmobilealliance.com/http://www.etsi.org/http://www.etsi.org/http://www.ietf.org/


31/31

Copyright 2013 Nokia Corporation. All rights reserved.

Nokia and Nokia Developer are trademarks or registered trademarks of Nokia Corporation. Other product and

company names mentioned herein may be trademarks or trade names of their respective owners.

Disclaimer

The information in this document is provided as is, with no warranties whatsoever, including any warranty of

merchantability, fitness for any particular purpose, or any warranty otherwise arising out of any proposal,

specification, or sample. This document is provided for informational purposes only.

Nokia Corporation disclaims all liability, including liability for infringement of any proprietary rights, relating to

implementation of information presented in this document. Nokia Corporation does not warrant or represent

that such use will not infringe such rights.

Nokia Corporation retains the right to make changes to this document at any time, without notice.

Licence

A licence is hereby granted to download and print a copy of this document for personal use only. No other licence

to any other intellectual property rights is granted herein.

Documents

Asha VoIP v1 0 Implementation Specifications v1 0 En