Nokia Series 40 VoIP v104 Implementation Specifications

Document created on 26 October 2011 Version 1.0

Table of contents
1. 2. Introduction Features
2.1 Basic call 2.1.1 Offer/Answer 2.1.2 Codec payloads 2.1.3 Comfort noise 2.1.4 Media QoS marking 2.1.5 Signaling QoS 2.1.6 DTMF Secure call Call forwarding Call transfer CLIP CLIR Message waiting indicator (MWI) NAT/FW traversal 2.8.1 STUN 2.8.2 Symmetric signalling 2.8.3 Symmetric media 2.8.4 Open ports for RTP/RTCP traffic 2.8.5 NAT binding keep alive Hold Call waiting Emergency call RTCP Extended Reports for VoIP metrics Phone management

3
4 5 6 10 11 11 12 12 13 14 15 15 16 17 17 17 18 18 18 19 20 20 20 22

2.2 2.3 2.4 2.5 2.6 2.7 2.8

2.9 2.10 2.11 2.12 2.13

3. 4.

Terms and abbreviations References

23 27

Change history
26 October 2011 Version 1.0 Initial document release

Nokia Series 40 VoIP v104 Implementation Specifications

1. Introduction
This document describes how the implementation of Nokia Series 40 Voice over IP (VoIP) v104 fulfils the Internet Engineering 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.

Nokia Series 40 VoIP v104 Implementation Specifications

2. Features
This section provides information on the specifications that each functional area of Nokia Series 40 Voice over IP (VoIP) v104 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 call

Related 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 sip:<telephone number>@<domain>, for example, sip:1234567@domain.com, that is the parameter user:phone is not included. (RFC 3824) 4

Nokia Series 40 VoIP v104 Implementation Specifications

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.)

2.1.1

Offer/Answer

Related 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 System Aspects; 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 the generation 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:) is according 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 sendonly when generating an offer for HOLD inside a session and recvonly when generating an ANSWER to a HOLD offer. Streams are marked as recvonly in ANSWER

Nokia Series 40 VoIP v104 Implementation Specifications

when inactive is received in an offer. Attribute sendrecv is 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 ptime and maxptime attributes. (Section 6.1, RFC 3264.)

One media stream (audio) only is supported. (Chapter 8, RFC 3264.) 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
AMR-NB

Codec payloads

Related specifications

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 Multi-Rate Wideband (AMR-WB) Audio Codecs [25] 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]

Nokia Series 40 VoIP v104 Implementation Specifications

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]

Nokia Series 40 VoIP v104 Implementation Specifications

Implementation notes
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 contain NO_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; single channel payload is supported (channels=1) and used by default if omitted in negotiation, and max-red; see Table 1 for the restrictions.
Table 1: Restrictions that apply to the handling of the max-red parameter are listed.

SDP offer

FEC defined in the provisioned VoIP settings

max-red is ptime multiplied by FEC. [54] defines

FEC not defined in the provisioned VoIP settings

Mobile Originated

the highest value for max-red as 220. If ptime multiplied by FEC exceeds 220, FEC will be set to 0 for that codec. If ptime is not defined in the settings, max-red is given the default ptime value of 20.

max-red is not advertised in the offer.

Nokia Series 40 VoIP v104 Implementation Specifications

SDP offer

FEC defined in the provisioned VoIP settings

If the received values for max-red and ptime are the same and the corresponding value has been defined for ptime in the settings, max-red is given the received value in the SDP answer. If the received value of ptime does not correspond with the received value of max-red or the value of ptime in the settings, max-red is set to 0 in the SDP answer. If ptime is not present in the received offer, maxred is given the default ptime value of 20 in the SDP answer.

FEC not defined in the provisioned VoIP settings

Mobile Terminated

If max-red is present in the received offer, it is set to 0 in the SDP answer. If max-red is not present in the offer, it will not be present in the answer.

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 are supported, maxptime, and annexb, value yes is implied if this parameter is omitted in negotiation.

Nokia Series 40 VoIP v104 Implementation Specifications

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 3551 depends on the provisioned VoIP settings, which are defined in the Nokia Series 40 VoIP v104 Configuration Tutorial. 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 noise

Related 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 Multi-Rate Wideband (AMR-WB) Audio Codecs [25]

Nokia Series 40 VoIP v104 Implementation Specifications

10

Implementation notes
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 for comfort 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 marking

Related 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 QoS

Related 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.

Nokia Series 40 VoIP v104 Implementation Specifications

11

2.1.6

DTMF

Related 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 call

Related 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. 12

Nokia Series 40 VoIP v104 Implementation Specifications

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, a fallback to non-secure call is attempted. If non-secure call is preferred in the provisioned VoIP settings: A non-secure call is attempted first. If the 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 forwarding

Related 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]

Implementation notes
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.

Nokia Series 40 VoIP v104 Implementation Specifications

13

2.4

Call transfer

Related 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]

Implementation notes
Support is provided for: 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-serviceexamples-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 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.)

Nokia Series 40 VoIP v104 Implementation Specifications

14

2.5

CLIP

Related 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]

Implementation notes
In the MO direction, when CLIP is on (that is, when CLIR is off), the Privacy header 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 From header.

2.6

CLIR

Related 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]

Implementation notes
In the MO direction, support is provided for: Privacy header. Note that the header value is id when CLIR is on. (Section 9.3, RFC 3325 and Section 4.2, RFC 3323.) From header, when CLIR is on, is set as Anonymous <sip:anonymous@anonymous.invalid>. (Section 4.1.1.3, RFC 3323.) In the MT direction, the From header is checked to determine if an anonymous call is being made.

Nokia Series 40 VoIP v104 Implementation Specifications

15

2.7

Message waiting indicator (MWI)

Related specifications
RFC 3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) [40]

Implementation notes
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 message summary. (Sections 3.5, RFC 3842). Following parameters are parsed from the NOTIFY content and shown on the UI (Sections 3.5 and 4.1, RFC 3842): 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.

Nokia Series 40 VoIP v104 Implementation Specifications

16

2.8
2.8.1

NAT/FW traversal
STUN

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

Implementation notes
Support is not provided for Binding Acquisition (Section 10.3, RFC 3489) except for STUN binding request/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 signalling

Related 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 STUN is 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 Via header field. (RFC 3581) This enables a client to request 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 VoIP settings), the Via header (from the first response to REGISTER) is checked for the received and 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.

Nokia Series 40 VoIP v104 Implementation Specifications

17

2.8.3

Symmetric media

Related 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-rtcpmux-07.txt [4].)

2.8.4

Open ports for RTP/RTCP traffic

Related 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 are obtained from STUN Binding Responses. Remote IP addresses for RTP and RTCP can be different. These are obtained from a remote SDP.

2.8.5
None.

NAT binding keep alive

Related specifications

Implementation notes
Firewall keep alive for uplink stream is started in the MO sessions every time a provisional answer with SDP content 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 and port.

Nokia Series 40 VoIP v104 Implementation Specifications

18

NAT and/or firewall bindings are kept alive by refreshing them while a session is in a hold state. If the address of 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 outbound proxy (for keep-alive). STUN binding request packets are sent to the networks STUN server (for detecting flow failure due to NAT reboot).

When TCP is used, STUN is not used for public address queries. TCP keep-alive (by sending a dummy octet packet 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

Hold

Related 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.

Nokia Series 40 VoIP v104 Implementation Specifications

19

2.10 Call waiting

Related 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 because another call is active at the receiving end.

2.11 Emergency call

VoIP emergency call is not supported. An emergency call is always made through the cellular network.

2.12 RTCP Extended Reports for VoIP metrics

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

Implementation notes
Supported and unsupported metrics of the VoIP metrics report block (Section 4.7, RFC 3611) are presented in Table 2.
Table 2: Supported and unsupported metrics of the VoIP metrics report block are listed.

Metrics of VoIP Metrics Report Block

Packet Loss and Discard Metrics Loss rate discard rate Burst Metrics burst density Gap density

Requirement level for compliance by RFC 3611

Supported by implementation

MUST MUST

Yes Yes

MUST MUST

Yes Yes

Nokia Series 40 VoIP v104 Implementation Specifications

20

Metrics of VoIP Metrics Report Block

burst duration Gap duration Delay Metrics round trip delay end system delay Signal Related Metrics signal level noise level residual echo return loss Call Quality or Transmission Quality Metrics R factor ext. R factor MOS-LQ MOS-CQ Configuration Parameters packet loss concealment jitter buffer adaptive jitter buffer rate Jitter Buffer Parameters jitter buffer nominal delay

Requirement level for compliance by RFC 3611

MUST MUST

Supported by implementation
Yes Yes

MUST SHOULD

Yes No

SHOULD SHOULD SHOULD

No No No

SHOULD SHOULD SHOULD SHOULD

No No No No

MUST MUST MUST

Yes Yes Yes

MUST

Yes

Nokia Series 40 VoIP v104 Implementation Specifications

21

Metrics of VoIP Metrics Report Block

jitter buffer maximum delay jitter buffer absolute maximum delay

Requirement level for compliance by RFC 3611

MUST MUST

Supported by implementation
Yes Yes

2.13 Phone management

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

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

Nokia Series 40 VoIP v104 Implementation Specifications

22

3. Terms and abbreviations

Term or abbreviation
3GPP a-law AKA AMR-NB AMR-WB AOR API CLIP CLIR CN CP CRC CRLF CS call DM DND DTMF DTX FEC

Meaning
The 3rd Generation Partnership Project Name of G.711 PCMU algorithm Authentication and Key Agreement Adaptive Multi-Rate Narrowband Adaptive Multi-Rate Wideband Address-of-record Application Programming Interface Calling Line Identification Presentation Calling Line Identification Restriction Comfort Noise Client Provisioning Cyclic Redundancy Check Formatting control codes Carriage Return (CR) and Line Feed (LF) Circuit-switched call Device Management Do Not Disturb Dual-Tone Multifrequency Discontinuous Transmission Forward Error Correction

Nokia Series 40 VoIP v104 Implementation Specifications

23

Term or abbreviation
FW GSM-EFR GSM-FR HTTP iLBC IEEE IETF IP IPv4 IPv6 ITU

Meaning
Firewall GSM Enhanced Full Rate GSM Full Rate Hyper Text Transport Protocol Internet Low Bitrate Codec The Institute of Electrical and Electronics Engineers, Inc. The Internet Engineering Task Force Internet Protocol Internet Protocol version 4 Internet Protocol version 6 International Telecommunication Union The maximum amount of media (in milliseconds) which can be encapsulated in a payload packet. Multipurpose Internet Mail Extensions Mobile Originated Mobile Terminated Message Waiting Indicator Network Address Translation Open Mobile Alliance Pulse Code Modulation a-law Pulse Code Modulation -law

Maxptime

MIME MO MT MWI NAT OMA PCMA PCMU

Nokia Series 40 VoIP v104 Implementation Specifications

24

Term or abbreviation

Meaning
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. Per-Hop Behaviour Packet-switched call Quality of Service Request For Comments Real-Time Transport Control Protocol RTCP Extended Reports Real-Time Transport Protocol Session Description Protocol Silence Insertion Descriptor Session Initiation Protocol Simple Traversal of UDP through NAT; a protocol that allows applications to detect that network address translation (NAT) is being used. Transmission Control Protocol User Datagram Protocol Unequal Error Detection Unequal Error Protection User Interface Uniform Resource Identifier Voice Activity Detection

Ptime

PHB PS call QoS RFC RTCP RTCP XR RTP SDP SID SIP

STUN

TCP UDP UED UEP UI URI VAD

Nokia Series 40 VoIP v104 Implementation Specifications

25

Term or abbreviation
VoIP -law

Meaning
Voice over IP Name of G.711 PCMU algorithm

Nokia Series 40 VoIP v104 Implementation Specifications

26

4.
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23]

References
3GPP TS 26.090, AMR Speech Codec; Transcoding Functions, available at http://www.3gpp.org/ draft-ietf-sipping-service-examples-12.txt, Session Initiation Protocol Service Examples, available at http://www.ietf.org/ RFC 4961, Symmetric RTP / RTP Control Protocol (RTCP), available at http://www.ietf.org/ draft-ietf-avt-rtp-and-rtcp-mux-07.txt, Multiplexing RTP Data and Control Packets on a Single Port, available at http://www.ietf.org/ ITU-T G.711 Appendix I, available at http://www.itu.int ITU-T G.711 Appendix II, available at http://www.itu.int ITU-T G.726, available at http://www.itu.int ITU-T G.729, available at http://www.itu.int ITU-T G.729 Annex B, available at http://www.itu.int RFC 2198, RTP Payload for Redundant Audio Data, available at http://www.ietf.org/ RFC 4566, SDP: Session Description Protocol, available at http://www.ietf.org/ RFC 3261, SIP: Session Initiation Protocol, available at http://www.ietf.org/ RFC 2617, HTTP Authentication: Basic and Digest Access Authentication, available at http://www.ietf.org/ RFC 4733, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, available at http://www.ietf.org/ RFC 3261, SIP: Session Initiation Protocol, available at http://www.ietf.org/ draft-ietf-sip-sips-06.txt, The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP), available at http://www.ietf.org/ RFC 3711, The Secure Real-time Transport Protocol (SRTP), available at http://www.ietf.org/ RFC 4568, Session Description Protocol (SDP) Security Descriptions for Media Streams, available at http://www.ietf.org/ RFC 3262, Reliability of Provisional Responses in the Session Initiation Protocol (SIP), available at http://www.ietf.org/ RFC 3263, Session Initiation Protocol (SIP): Locating SIP Servers, available at http://www.ietf.org/ RFC 2782, A DNS RR for specifying the location of services (DNS SRV), available at http://www.ietf.org/ RFC 2915, The Naming Authority Pointer (NAPTR) DNS Resource Record, available at http://www.ietf.org/ RFC 3264, An Offer/Answer Model with the Session Description Protocol (SDP), available at http://www.ietf.org/

Nokia Series 40 VoIP v104 Implementation Specifications

27

[24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45]

RFC 4856, Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences, available at http://www.ietf.org/ RFC 4867, RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs, available at http://www.ietf.org/ RFC 3310, Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA), available at http://www.ietf.org/ RFC 3323, A Privacy Mechanism for the Session Initiation Protocol (SIP), available at http://www.ietf.org/ RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks, available at http://www.ietf.org/ RFC 3389, RTP Payload for Comfort Noise (CN), available at http://www.ietf.org/ RFC 3489, STUN: Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), available at http://www.ietf.org/ RFC 3515, The Session Initiation Protocol (SIP) Refer Method, available at http://www.ietf.org/ RFC 3550, RTP: A Transport Protocol for Real-Time Applications, available at http://www.ietf.org/ RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control, available at http://www.ietf.org/ ITU-T I.366.2, AAL type 2 service specific convergence sublayer for trunking, available at http://www.itu.int RFC 4855, Media Type Registration of RTP Payload Formats, available at http://www.ietf.org/ RFC 3581, An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing, available at http://www.ietf.org/ RFC 3605, Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP), available at http://www.ietf.org/ RFC 3665, Session Initiation Protocol (SIP) Basic Call Flow Examples, available at http://www.ietf.org/ RFC 3824, Using E.164 numbers with the Session Initiation Protocol (S IP), available at http://www.ietf.org/ RFC 3842, A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP), available at http://www.ietf.org/ RFC 3891, The Session Initiation Protocol (SIP) "Replaces" Header, available at http://www.ietf.org/ RFC 3892, The Session Initiation Protocol (SIP) Referred-By Mechanism, available at http://www.ietf.org/ RFC 3960, Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP), available at http://www.ietf.org/ ETSI TS 183 004 PSTN/ISDN simulation services: Communication Diversion (CDIV); Protocol specification V1.1.1, available at http://www.etsi.org ETSI TS 183 029 PSTN/ISDN simulation services: Explicit Communication Transfer (ECT); Protocol specification V1.1.1, available at http://www.etsi.org 28

Nokia Series 40 VoIP v104 Implementation Specifications

[46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57]

OMA Device Management v1.1.2, available at http://www.openmobilealliance.com/ OMA Client Provisioning v1.1, available at http://www.openmobilealliance.com/ RFC 3951, Internet Low Bit Rate Codec (iLBC), available at http://www.ietf.org/ RFC 3952 , RTP Payload Format for iLBC Speech, available at http://www.ietf.org/ RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, available at http://www.ietf.org/ 3GPP TS 26.190, Wideband (AMR-WB) speech codec; Transcoding Functions, available at http://www.3gpp.org/ 3GPP TS 46.010, Full rate speech; Transcoding, available at http://www.3gpp.org/ 3GPP TS 46.060, Enhanced Full Rate (EFR) speech transcoding, available at http://www.3gpp.org/ 3GPP TS 26.114, Media handling and interaction, available at http://www.3gpp.org/ RFC 3611 , RTP Control Protocol Extended Reports (RTCP XR), available at http://www.ietf.org/ RFC 3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth, available at http://www.ietf.org/ 3GPP 26.114 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction (Release 8) v8.4, available at http://www.3gpp.org

Nokia Series 40 VoIP v104 Implementation Specifications

29

Copyright 2011 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.

Nokia Series 40 VoIP v104 Implementation Specifications

30