30
Nokia Series 40 VoIP v104 Implementation Specifications Document created on 26 October 2011 Version 1.0

Series 40 VoIP v104 Implementation Specifications v1 0 En

Embed Size (px)

Citation preview

Page 1: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications

Document created on 26 October 2011

Version 1.0

Page 2: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 2

Table of contents 1. Introduction 3

2. Features 4 2.1 Basic call 4

2.1.1 Offer/Answer 5 2.1.2 Codec payloads 6 2.1.3 Comfort noise 10 2.1.4 Media QoS marking 11 2.1.5 Signaling QoS 11 2.1.6 DTMF 12

2.2 Secure call 12 2.3 Call forwarding 13 2.4 Call transfer 14 2.5 CLIP 15 2.6 CLIR 15 2.7 Message waiting indicator (MWI) 16 2.8 NAT/FW traversal 17

2.8.1 STUN 17 2.8.2 Symmetric signalling 17 2.8.3 Symmetric media 18 2.8.4 Open ports for RTP/RTCP traffic 18 2.8.5 NAT binding keep alive 18

2.9 Hold 19 2.10 Call waiting 20 2.11 Emergency call 20 2.12 RTCP Extended Reports for VoIP metrics 20 2.13 Phone management 22

3. Terms and abbreviations 23

4. References 27

Change history 26 October 2011 Version 1.0 Initial document release

Page 3: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 3

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.

Page 4: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 4

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:[email protected], that is the parameter user:phone is not included. (RFC 3824)

Page 5: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 5

• 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

Page 6: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 6

when inactive is received in an offer. Attribute sendrecv

• Every ANSWER to any offer contains the most preferred supported codec only. (Section 6.1, RFC 3264.)

is used when resuming from HOLD (in offer

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

• Packetisation interval is supported with ptime and maxptime

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

attributes. (Section 6.1, 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 Codec payloads

Related 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

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]

Page 7: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 7

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

Page 8: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 8

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

Table 1

) and used by default if omitted in negotiation, and max-red;

see 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 FEC not defined in the provisioned VoIP settings

Mobile Originated

max-red is ptime multiplied by FEC. [54] defines 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.

.

Page 9: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 9

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

Mobile Terminated

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, max-red is given the default ptime value of 20

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

in the SDP answer.

0

‒ G.711:

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

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

Page 10: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 10

‒ 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

‒ Payload types:

) is used by default if omitted in negotiation.

• 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 phone’s 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]

Page 11: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 11

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.

Page 12: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 12

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.

Page 13: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 13

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

Page 14: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 14

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

Page 15: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 15

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

‒ 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

header is omitted.

From

2.6 CLIR

header.

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:[email protected]>

‒ In the MT direction, the

. (Section

4.1.1.3, RFC 3323.)

From header is checked to determine if an anonymous call is being made.

Page 16: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 16

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.

Page 17: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 17

2.8 NAT/FW traversal

2.8.1 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

‒ When SIP registration is undertaken over TCP (or over UDP when STUN is disabled in the provisioned VoIP

settings), the

header field. (RFC 3581) This enables a client to

request that the server sends the response back to the request’s source IP address and port.

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

‒ Default port number 5060 is used for SIP signalling if not otherwise discovered.

is used).

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

‒ For the symmetric SIP signalling, SIP requests and responses are received and sent from the same address

and port.

Page 18: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 18

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-rtcp-

mux-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 NAT binding keep alive

Related specifications

‒ None.

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.

Page 19: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 19

‒ 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 network’s 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 network’s 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.

Page 20: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 20

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 Requirement level for compliance by RFC 3611

Supported by implementation

Packet Loss and Discard Metrics

Loss rate MUST Yes

discard rate MUST Yes

Burst Metrics

burst density MUST Yes

Gap density MUST Yes

Page 21: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 21

Metrics of VoIP Metrics Report Block Requirement level for compliance by RFC 3611

Supported by implementation

burst duration MUST Yes

Gap duration MUST Yes

Delay Metrics

round 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 Metrics

R factor SHOULD No

ext. R factor SHOULD No

MOS-LQ SHOULD No

MOS-CQ SHOULD No

Configuration Parameters

packet loss concealment MUST Yes

jitter buffer adaptive MUST Yes

jitter buffer rate MUST Yes

Jitter Buffer Parameters

jitter buffer nominal delay MUST Yes

Page 22: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 22

Metrics of VoIP Metrics Report Block Requirement level for compliance by RFC 3611

Supported by implementation

jitter buffer maximum delay MUST Yes

jitter buffer absolute maximum delay MUST 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.

Page 23: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 23

3. Terms and abbreviations Term 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

FEC Forward Error Correction

Page 24: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 24

Term or abbreviation Meaning

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

Maxptime The 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

PCMU Pulse Code Modulation µ-law

Page 25: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 25

Term or abbreviation Meaning

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

STUN Simple 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

VAD Voice Activity Detection

Page 26: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 26

Term or abbreviation Meaning

VoIP Voice over IP

µ-law Name of G.711 PCMU algorithm

Page 27: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 27

4. References [1] 3GPP TS 26.090, AMR Speech Codec; Transcoding Functions, available at http://www.3gpp.org/

[2] draft-ietf-sipping-service-examples-12.txt, Session Initiation Protocol Service Examples, available at http://www.ietf.org/

[3] RFC 4961, Symmetric RTP / RTP Control Protocol (RTCP), available at http://www.ietf.org/

[4] 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/

[5] ITU-T G.711 Appendix I, available at http://www.itu.int

[6] ITU-T G.711 Appendix II, available at http://www.itu.int

[7] ITU-T G.726, available at http://www.itu.int

[8] ITU-T G.729, available at http://www.itu.int

[9] ITU-T G.729 Annex B, available at http://www.itu.int

[10] RFC 2198, RTP Payload for Redundant Audio Data, available at http://www.ietf.org/

[11] RFC 4566, SDP: Session Description Protocol, available at http://www.ietf.org/

[12] RFC 3261, SIP: Session Initiation Protocol, available at http://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 at http://www.ietf.org/

[15] RFC 3261, SIP: Session Initiation Protocol, available at http://www.ietf.org/

[16] 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/

[17] RFC 3711, The Secure Real-time Transport Protocol (SRTP), available at http://www.ietf.org/

[18] RFC 4568, Session Description Protocol (SDP) Security Descriptions for Media Streams, available at http://www.ietf.org/

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

[20] RFC 3263, Session Initiation Protocol (SIP): Locating SIP Servers, available at http://www.ietf.org/

[21] RFC 2782, A DNS RR for specifying the location of services (DNS SRV), available at http://www.ietf.org/

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

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

Page 28: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 28

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

[25] 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/

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

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

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

[29] RFC 3389, RTP Payload for Comfort Noise (CN), available at http://www.ietf.org/

[30] RFC 3489, STUN: Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), available at http://www.ietf.org/

[31] RFC 3515, The Session Initiation Protocol (SIP) Refer Method, available at http://www.ietf.org/

[32] RFC 3550, RTP: A Transport Protocol for Real-Time Applications, available at http://www.ietf.org/

[33] RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control, available at http://www.ietf.org/

[34] ITU-T I.366.2, AAL type 2 service specific convergence sublayer for trunking, available at http://www.itu.int

[35] RFC 4855, Media Type Registration of RTP Payload Formats, available at http://www.ietf.org/

[36] RFC 3581, An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing, available at http://www.ietf.org/

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

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

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

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

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

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

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

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

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

Page 29: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 29

[46] OMA Device Management v1.1.2, available at http://www.openmobilealliance.com/

[47] OMA Client Provisioning v1.1, available at http://www.openmobilealliance.com/

[48] RFC 3951, Internet Low Bit Rate Codec (iLBC), available at http://www.ietf.org/

[49] RFC 3952 , RTP Payload Format for iLBC Speech, available at http://www.ietf.org/

[50] RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, available at http://www.ietf.org/

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

[52] 3GPP TS 46.010, Full rate speech; Transcoding, available at http://www.3gpp.org/

[53] 3GPP TS 46.060, Enhanced Full Rate (EFR) speech transcoding, available at http://www.3gpp.org/

[54] 3GPP TS 26.114, Media handling and interaction, available at http://www.3gpp.org/

[55] RFC 3611 , RTP Control Protocol Extended Reports (RTCP XR), available at http://www.ietf.org/

[56] RFC 3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth, available at http://www.ietf.org/

[57] 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

Page 30: Series 40 VoIP v104 Implementation Specifications v1 0 En

Nokia Series 40 VoIP v104 Implementation Specifications 30

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.