-
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
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
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
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
3/31
Nokia Asha VoIP v1.0 Implementation Specifications 3
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.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
4/31
Nokia Asha VoIP v1.0 Implementation Specifications 4
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)
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
5/31
Nokia Asha VoIP v1.0 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.)
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
6/31
Nokia Asha VoIP v1.0 Implementation Specifications 6
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.)
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
7/31
Nokia Asha VoIP v1.0 Implementation Specifications 7
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
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]
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
8/31
Nokia Asha VoIP v1.0 Implementation Specifications 8
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]
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
9/31
Nokia Asha VoIP v1.0 Implementation Specifications 9
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 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.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
10/31
Nokia Asha VoIP v1.0 Implementation Specifications 10
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.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
11/31
Nokia Asha VoIP v1.0 Implementation Specifications 11
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
Multi-Rate Wideband (AMR-WB) Audio Codecs[25]
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 -
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
12/31
Nokia Asha VoIP v1.0 Implementation Specifications 12
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 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.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
13/31
Nokia Asha VoIP v1.0 Implementation Specifications 13
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.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
14/31
Nokia Asha VoIP v1.0 Implementation Specifications 14
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]
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.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
15/31
Nokia Asha VoIP v1.0 Implementation Specifications 15
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]
Implementation notes
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.)
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
16/31
Nokia Asha VoIP v1.0 Implementation Specifications 16
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]
Implementation notes
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]
Implementation notes
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.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
17/31
Nokia Asha VoIP v1.0 Implementation Specifications 17
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]
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 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.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
18/31
Nokia Asha VoIP v1.0 Implementation Specifications 18
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]
Implementation notes
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.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
19/31
Nokia Asha VoIP v1.0 Implementation Specifications 19
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.
Implementation notes
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.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
20/31
Nokia Asha VoIP v1.0 Implementation Specifications 20
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.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
21/31
Nokia Asha VoIP v1.0 Implementation Specifications 21
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]
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
22/31
Nokia Asha VoIP v1.0 Implementation Specifications 22
Implementation notes
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
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
23/31
Nokia Asha VoIP v1.0 Implementation Specifications 23
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]
Implementation notes
Support is provided for: OMA Device Management version 1.1.2. OMA Client Provisioning version 1.1.
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
24/31
Nokia Asha VoIP v1.0 Implementation Specifications 24
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
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
25/31
Nokia Asha VoIP v1.0 Implementation Specifications 25
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
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
26/31
Nokia Asha VoIP v1.0 Implementation Specifications 26
Term or abbreviation Meaning
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
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
27/31
Nokia Asha VoIP v1.0 Implementation Specifications 27
Term or abbreviation Meaning
VAD Voice Activity Detection
VoIP Voice over IP
-law Name of G.711 PCMU algorithm
-
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
28/31
Nokia Asha VoIP v1.0 Implementation Specifications 28
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
http://www.ietf.org/
[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/ -
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
29/31
Nokia Asha VoIP v1.0 Implementation Specifications 29
[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
http://www.ietf.org/
[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,
available athttp://www.ietf.org/
[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/ -
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
30/31
Nokia Asha VoIP v1.0 Implementation Specifications 30
[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,
available athttp://www.ietf.org/
[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/ -
8/12/2019 Asha VoIP v1 0 Implementation Specifications v1 0 En
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.