idnits 2.17.1 draft-ietf-avt-rtp-retransmission-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-ietf-avt-rtp-retransmission-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-avt-rtp-retransmission-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-avt-rtp-retransmission-', but the file name used is 'draft-ietf-avt-rtp-retransmission-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 2002) is 8076 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 74 looks like a reference -- Missing reference section? '2' on line 90 looks like a reference -- Missing reference section? '3' on line 110 looks like a reference -- Missing reference section? '4' on line 386 looks like a reference -- Missing reference section? '5' on line 424 looks like a reference -- Missing reference section? '6' on line 137 looks like a reference -- Missing reference section? '7' on line 405 looks like a reference -- Missing reference section? '8' on line 412 looks like a reference Summary: 4 errors (**), 1 flaw (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 David Leon 3 Internet Draft Viktor Varsa 4 Document: draft-ietf-avt-rtp-retransmission- Nokia 5 00.txt 6 Expires: September 2002 March 2002 8 RTP retransmission framework 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 RTP retransmission is an effective packet loss recovery scheme for 33 real-time applications with relaxed delay bounds. 35 This document describes an RTP retransmission framework. It defines 36 a payload format for retransmitted packets and recommends rules for 37 sending these packets. Retransmitted RTP packets are sent in a 38 separate stream from the original RTP stream. It is assumed that 39 feedback from receivers to senders indicating the occurred packet 40 losses is available by some means not defined here. 42 Main changes since draft-leon-rtp-retransmission-02.txt 44 The previous version of the draft described the use of the 45 redundancy payload format (RFC 2198) in order to send retransmission 46 data and original data in the same stream. At IETF #53, it was 47 concluded that RFC 2198 was not intended to such a use. Piggybacking 48 retransmitted packets was thus removed from the draft. 50 Table of Contents 52 Abstract...........................................................1 53 Main changes since draft-leon-rtp-retransmission-02.txt............1 54 1. Introduction....................................................2 55 2. Terminology.....................................................2 56 3. Retransmission framework basic principles.......................3 57 4. Retransmission payload format...................................4 58 5. Use with the Extended RTP profile for RTCP-based feedback.......5 59 6. Congestion control..............................................7 60 7. Example scenario of unicast streaming...........................8 61 8. SDP usage.......................................................8 62 9. FEC for retransmission..........................................9 63 10. Security consideration........................................10 64 11. References....................................................10 65 Author's Addresses................................................11 67 1. Introduction 69 Packet losses between an RTP sender and receiver may significantly 70 degrade the quality of the received signal. Several techniques, such 71 as forward error correction (FEC), retransmissions or adaptation of 72 application layer (e.g. video) error resilience techniques based on 73 back-channel messages may be considered to increase the robustness 74 to packet loss. RFC-2354 [1] discusses the different options. 76 When choosing a technique for a particular system, the tolerable 77 latency of the application has to be taken into account. In the case 78 of multimedia conferencing, the end-to-end delay has to be at most a 79 few hundred milliseconds in order to guarantee interactivity, which 80 usually excludes the use of retransmission. On the other hand, in 81 the case of multimedia streaming, the user can tolerate an initial 82 latency as part of the session setup and thus an end-to-end delay of 83 several seconds is possible. Retransmission may thus be considered 84 for such applications. 86 This document proposes a retransmission framework. It defines a 87 payload format for retransmitted RTP packets and retransmission 88 rules. This RTP retransmission scheme requires frequent packet loss 89 indication feedback to the RTP entity performing retransmission. The 90 AV profile [2] does not provide this feature and could therefore not 91 be used. However, the retransmission scheme could be run under the 92 extended RTP profile for RTCP-based feedback[3] which defines a NACK 93 message that can be sent as part of a compound RTCP packet. 95 2. Terminology 96 The following terms are used in this document: 98 Original packet: refers to an RTP packet sent by an RTP sender as 99 part of an RTP stream. 101 Original stream: refers to the stream of original packets. 103 Retransmission packet: refers to an RTP packet whose payload 104 includes the payload of an already sent original packet. Such a 105 retransmission packet is said to be associated with the original RTP 106 packet whose payload is included in the retransmission packet. 108 Retransmission request: a means by which an RTP receiver is able to 109 request that the RTP sender send a retransmission packet associated 110 with a given original packet. In [3], a retransmission request is 111 sent as a packet loss indication in a NACK message. 113 Retransmission stream: the stream of retransmission packets 114 associated to with an original stream. 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 118 this document are to be interpreted as described in RFC-2119 [4]. 120 3. Retransmission framework basic principles 122 Retransmission packets MUST NOT share the RTP Sequence Number (SN) 123 space with the original stream. The retransmission stream SHOULD use 124 a different RTP session (as defined in RTP [5]) from that of the 125 original stream. Since a separate session is used, the original and 126 retransmission streams are sent to different multicast group/unicast 127 addresses and/or port numbers. The retransmission stream has then 128 its own SN space.. 130 There are several reasons why the SN space must not be shared: 132 Since retransmission packets do not share the SN space with the 133 original packets, the receiver is able to distinguish between the 134 loss of original packets and retransmission packets. Otherwise, 135 reliable data loss detection would not be possible. Reliable data 136 loss detection is mandated for example in RTP conversational text 137 [6]. 139 RTP Timestamp (TS) estimation of missing original packets is 140 necessary at the receiver in order to decide whether a 141 retransmission is useful or not. A retransmission is useful if the 142 retransmission packet as a response to the retransmission request is 143 estimated to arrive at the receiver before the time it is used for 144 playback (playout time). The missing original packet TS can be 145 estimated from TS of packets preceding and following the SN gap 146 caused by the missing packet in the original stream. 148 The fact that RTP streams for original and retransmission packets do 149 not share the same SN space guarantees that the RTP timestamp 150 estimation method is reliable. Reliability would be sacrificed if 151 original and retransmission packets were sent in the same RTP 152 stream. The TS estimate for a lost retransmission packet ,when 153 calculated as above, would then be incorrect. This is because the 154 retransmission packet usually has a smaller "out-of-order" TS than 155 the TS of the consecutive original packets. 157 There are no modifications to the payload format of the original 158 packets. Retransmission can thus work with any existing payload 159 format. 161 When the retransmission stream is sent to a multicast RTP session, 162 receivers may choose to subscribe or not to subscribe to the RTP 163 session carrying the retransmission stream. Thus, a multicast 164 streaming application can use retransmission and still be backwards 165 compatible as receivers which do not implement the retransmission 166 payload format only join the RTP session carrying the original 167 stream. A scenario where the original session is multicast and 168 separate unicast sessions carry the retransmission stream to each 169 participant, is also possible. In this scenario, a receiver can 170 receive retransmission packets only for original packets that it has 171 itself requested, and not the retransmission packets that are sent 172 as responses to retransmission requests from other receivers. 174 Mixers, translators and packet caches may be able to separate 175 retransmission packets from original packets at an RTP session level 176 and process them differently if necessary. 178 As a consequence of having separate RTP sessions for original and 179 retransmission streams, there are also separate RTCP streams and 180 statistics for these two sessions. There is thus no corruption of 181 the original stream RTCP statistics. The RTP sender is able to know 182 the packet loss and jitter of the original stream. It can thus 183 estimate what the quality of the received signal would be without 184 the use of retransmission. 186 4. Retransmission payload format 188 The payload format of a retransmission packet is shown below. 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | RTP Header | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |E| OPT | OSN | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 195 | Original RTP Packet Payload | 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 RTP header usage: 199 The same SSRC value SHOULD be used for the original stream and the 200 retransmission stream. In the RTP header, SN has the standard 201 definition, i.e. it MUST be one higher than the SN of the preceding 202 retransmission packet. The payload type is dynamic and indicates the 203 use of the retransmission payload format. All other fields of the 204 RTP header have the same value as in the original RTP packet. 206 The retransmission packet payload carries an E bit, an OPT field (7 207 bits) and an OSN field (2 bytes) followed by the original RTP packet 208 payload. The E bit is an extension bit for future-proofing. It MUST 209 be set to zero. The OPT field is the payload type of the original 210 packet payload that is being retransmitted. The OSN field is the SN 211 of the original packet that originally carried the same payload. 213 5. Use with the Extended RTP profile for RTCP-based feedback 215 When the Extended RTP profile for RTCP-based feedback [4] is used, 216 it is RECOMMENDED that receivers send retransmission requests 217 according to the rules in this section. The rules described 218 hereafter aim at limiting the maximum delay before a retransmission 219 request can be sent and are compliant to the more general rules 220 described in the profile itself. 222 5.1 Sending rules for RTCP-based feedback 224 The minimum RTCP report interval is computed according to the 225 allowed RTCP bandwidth of a given session (obtained explicitly or 226 calculated as a percentage of the RTP session bandwidth). The NACK 227 message format defined in the profile is used. Early RTCP packets 228 SHOULD NOT be used, and the NACK message SHOULD always be appended 229 to a regularly scheduled compound RTCP packet that is sent at every 230 RTCP report interval T_rr. 232 Any other rules to send feedback MAY be used as long as they are 233 compliant with the profile in use. In particular, a receiver MAY 234 send NACK messages in early RTCP packets. However, in that case the 235 time when the next RTCP packet following this early RTCP packet can 236 be sent could be too late to report a loss occurring right after the 237 early RTCP packet was sent. Sending RTCP packets at regular 238 intervals guarantees that the delay between detecting an original 239 packet loss and being able to send a NACK message for that packet is 240 no longer than the regular RTCP interval. 242 A receiver should compute an estimate of the delay D to receive a 243 retransmission packet after a NACK message has been sent. This 244 estimate may be obtained from past observations, RTCP report round- 245 trip time if available or any other means. 247 The minimum receiver buffering delay B (i.e. the time between a 248 packet is received and its payload is used at the receiver) is the 249 RTCP reporting interval added to the delay estimate, which 250 guarantees that a retransmission packet as a response to a sent 251 retransmission request can be received before its payload is used. 252 i.e. 253 B>T_rr+D 255 It can be seen that the needed receiver buffering delay is dependent 256 on the amount of RTCP traffic allowed in the session. It is 257 illustrated in Section 7 that moderate RTCP feedback traffic is 258 enough to perform retransmission with reasonable receiver buffering 259 delay. 261 5.2 Receiver algorithm for generating retransmission requests 263 A receiver needs to maintain a list of missing original packet 264 sequence numbers (SN) since its last sent RTCP packet. A receiver 265 needs also to store for each missing original packet an estimated 266 RTP timestamp (TS) as described in Section 3. 268 At the next scheduled RTCP packet time, the receiver estimates based 269 on the estimated TS of the missing original packet if a 270 retransmission packet as a response to a NACK message that would be 271 sent in the current RTCP packet could arrive at the receiver before 272 its playout time or not. If not, it removes the packet SN from its 273 list of missing packets. The receiver then sends retransmission 274 requests for the missing original packets by adding the SNs of the 275 missing original packets to a NACK message in the scheduled RTCP 276 compound packet (see usage of the PID and BLP fields of the NACK 277 message format in [4]). If needed for signalling of multiple missing 278 SN, multiple NACK messages can be added to the RTCP compound 279 packet.. 281 If the retransmission stream is sent to a multicast session, the 282 receiver SHOULD listen to NACK messages from other receivers. If a 283 NACK message for the SN of a missing packet at the receiver has been 284 sent by another receiver, the receiver SHOULD ignore that SN in its 285 list of missing packets and refrain from sending a retransmission 286 request for that SN. 288 The same retransmission request may be resent by the receiver if no 289 retransmission packet with OSN equal to the missing original packet 290 SN was received after an estimated retransmission reception time. 291 This increases robustness to the loss of a NACK message or of a 292 retransmission packet. The repeated retransmission request may be 293 sent at the earliest at the next RTCP report scheduled time. 294 Repeated retransmission requests MUST be sent in the original RTP 295 session and not in the retransmission RTP session. The number of 296 repeated retransmission requests that may be sent for a given 297 missing original packet SN depends on the ratio of the receiver 298 buffering delay and RTCP session bandwidth. 300 The receiver should upon reception of a retransmission packet remove 301 the SN corresponding to the original packet (OSN in the 302 retransmission payload format) from the list of missing SNs. 304 5.3 RTCP sending rules in the retransmission RTP session 306 Since the original stream and the retransmission stream are carried 307 in separate RTP sessions, the retransmission stream has its own RTCP 308 stream as well. The amount of RTCP sent for the retransmission 309 stream is computed as a fraction of the retransmission RTP session 310 bandwidth. Since the retransmission traffic is limited, the overhead 311 caused by the additional RTCP packets in the retransmission RTP 312 session is moderate. For example, assuming a 64 kbps original RTP 313 session and on average 3% packet loss and all lost original packets 314 retransmitted once, the bandwidth of the retransmission RTP session 315 would be about 2 kbps. In this case the recommended RTCP traffic for 316 the retransmission RTP session would be 0.1 kbps. 318 Early RTCP packets and RTCP feedback messages SHOULD NOT be used in 319 the retransmission RTP session. 321 6. Congestion control 323 RTP retransmission poses a risk of increased network congestion. In 324 a best-effort environment, packet loss is caused by congestion. 325 Reacting to loss by retransmitting older packets in addition to the 326 current data would thus further increase congestion. Implementations 327 SHOULD follow the recommendations below in order to use 328 retransmission. 330 The RTP profile under which the retransmission scheme is used 331 defines an appropriate congestion control mechanism in different 332 environments. Following the rules under this profile, an RTP 333 application can determine its acceptable bitrate and packet rate in 334 order to be fair to other applications such as TCP flows and other 335 RTP flows. 337 If an RTP application uses retransmission, the acceptable packet 338 rate and bitrate SHOULD include both the original and retransmitted 339 data. This will guarantee that an application using retransmission 340 should be fair to any other RTP or TCP flows. Such a rule would 341 translate in practice into the following actions: 343 If enhanced service is used it should made sure that the total 344 bitrate and packet rate do not exceed that of the requested service. 345 It should be further monitored that the requested services are 346 actually delivered. In a best-effort environment, the sender SHOULD 347 NOT send retransmission packets without reducing the packet rate and 348 bitrate of the original stream (for example by encoding the data at 349 a lower rate). 351 In addition, the sender MAY retransmit only the packets that it 352 deems important and ignore NACK messages for other packets in order 353 to limit the bitrate 355 These congestion control mechanisms should keep the congestion level 356 under an acceptable limit. This would in turn guarantee that the 357 packet loss should be moderate. Too high a packet loss would mean 358 that congestion is not kept under control and retransmission should 359 then not be used. 361 7. Example scenario of unicast streaming 363 Let us assume that the RTP session bandwidth is 64 kbps and the 364 receiver buffering delay is 3 seconds. The network round trip time 365 is 500 ms and Receiver RTCP packets are sent at 2-second intervals 366 from the receiver including NACK messages for missing original 367 packet SNs. With these time limitations, when the receiver algorithm 368 for generating retransmission requests described in Section 5.2 is 369 followed, only one NACK message but no repeated NACK messages can be 370 sent for the same original packet loss. Let us assume an original 371 packet rate of 50 packets per second (1 packet every 20 ms). At this 372 packet rate in a packet loss distribution worst case scenario where 373 every 17th original packet is lost (i.e. 5.88% uniform packet loss), 374 a maximum of 6 NACK messages need to be appended to the RTCP 375 compound packet that is sent every 2 seconds. The 6 NACK messages 376 can report any packet losses in an SN range of 6*17=102, thus the 377 number of required NACK messages would not increase with higher 378 packet loss rates. The overhead required per RTCP compound packet 379 for the 6 NACK messages is 36 bytes which carries 6 PID and 6 BLP 380 fields in addition to the feedback message headers. 382 The total compound RTCP packets size is thus: IPv4 (20) + UDP (8)+ 383 RR(header 8 + report 24)+ CNAME(12)+ NACK (36) = 108 bytes. The 384 needed receiver RTCP bandwidth would then be 0.432 kbps. This RTCP 385 bandwidth is well below the maximum allowed RTCP bandwidth that 386 would be allowed when using [4]. From the receiver to the sender the 387 RTCP bandwidth limit in an RTP session with 64 kbps is about 0.25*64 388 = 1.6 kbps. 390 8. SDP usage 392 The binding to the payload type number is indicated by an rtpmap 393 attribute. The name used in the binding is "RTX".. 395 c=IN IP4 113.3.12.11 396 m=video 49170 RTP/AVPF 96 397 a=rtpmap:96 H263-1998/90000 398 a=fmtp:96 rtcp-fb nack 399 m=video 49172 RTP/AVPF 97 400 a=rtpmap:97 RTX/90000 402 9. FEC for retransmission 404 It is possible to retransmit the payload of an original packet by 405 sending a FEC packet as defined in [7] instead of using the 406 retransmission payload format. The base SN of the FEC header is the 407 sequence number of the original packet that carried the same payload 408 and the mask is set to zero. There are some advantages in using the 409 FEC payload format in particular in multicast sessions as a single 410 FEC packet may repair the loss of different packets at different 411 receivers. In a multicast session, FEC may be combined with 412 retransmission requests as described in [8] in order to achieve 413 scalable reliable multicast transmission. 415 There are however some motivations to define the retransmission 416 payload format in order to perform retransmission instead of using 417 the FEC payload format: 419 *The retransmission payload format has reduced overhead (3 bytes 420 instead of 12 bytes). 422 *In the retransmission payload format, the RTP header TS is the 423 actual TS of the (retransmitted) media carried in the packets. This 424 is in line with RTP [5] specifications. This is useful in particular 425 for RTP mixers/translators which process the TS. On the other hand, 426 the FEC payload format uses the RTP transmission time (as the FEC 427 packet should be computed over data with different TS). 429 *Assuming that no retransmission payload format were defined, the 430 FEC payload format would then be used in different ways: sending 431 computed FEC packets proactively for correction of lost packets at 432 the receiver without requiring NACK messages (referred hereafter as 433 proactive FEC) or sending retransmitted data upon receipt of a NACK 434 message from the receiver. 435 Although they could use the same payload format, these two repair 436 mechanisms are different. For a given amount of overhead, they offer 437 a different residual packet loss vs. latency trade-off. 438 Retransmission provides higher packet loss recovery at the expense 439 of higher delay. If a sender uses proactive FEC and none of the 440 packets protected by a given FEC packet is lost, there is then no 441 use of the FEC packet at the receiver. On the other hand, data which 442 are retransmitted are known to have been lost. 443 Therefore, a receiver may wish to use only retransmission and not 444 receive any proactive FEC from the sender in order to trade-off 445 itself the buffering delay, the data-loss rate and the overhead. 446 There is thus a motivation to let the receiver decide at session 447 setup whether the sender may send proactive FEC or retransmission 448 only. 449 If the same payload format were used for these different purposes, 450 the receiver would not know at session establishment which repair 451 mechanism is used by the sender (without defining out-of-band 452 signalling). The sender would decide by itself whether FEC or 453 retransmission (or both) is used and the receiver would not know 454 until receiving the FEC packets whether proactive FEC or 455 retransmission is used. 456 On the other hand, having different payload formats or at least 457 different out of band signalling for these two repair mechanisms 458 (e.g. through defining the binding name 'RTX' SDP rtpmap attribute) 459 would allow the receiver to choose which mechanism to use (among 460 those supported by the sender). The receiver would then have an 461 explicit way to tell the sender not to send proactive FEC. 462 Furthermore, if the receiver did not know at session establishment 463 whether it will receive FEC packets or retransmission, it would have 464 to be prepared to receive FEC and thus be able to perform FEC packet 465 recovery operations. Implementers could thus not choose to implement 466 only a FEC or retransmission scheme. 468 10. Security consideration 470 The security considerations of the profile under which the 471 retransmission scheme is used should be applied. 473 11. References 475 1 Perkins, C., Hodson, O., "Options for Repair of Streaming Media", 476 RFC 2354, June 1998. 478 2 Schulzrinne, H and Casner, S. " RTP Profile for Audio and 479 VideoConferences with Minimal Control," Internet Draft draft- 480 ietf-avt-profile-new-12.txt, November 2001. 482 3 J Ott, S Wenger, S Fukunaga, N Sato, K Yano, M Akihiro, H Koichi, 483 R Hakenberg, C. Burmeister "Extended RTP profile for RTCP-based 484 feedback", November 2001 486 4 RFC 2119 S Bradner ., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997 489 5 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: 490 A Transport Protocol for Real-Time Applications", Internet Draft 491 draft-ietf-avt-rtp-new-11.txt, November 2001. 493 6 Hellstrom, J, "RTP for conversational text", RFC 2793, May 2000 495 7 Rosenberg, J. and Schulzrinne, H., " An RTP Payload Format for 496 Generic Forward Error Correction", RFC 2733, December 1999. 498 8 Nonnenmacher, Biersack, E, Towsley, D,. "Parity-based loss 499 recovery for reliable multicast transmission", ACM SIGCOMM'97, 500 Cannes, France, September 1997 501 Author's Addresses 503 David Leon 504 Nokia Research Center 505 6000 Connection Drive Phone: 1-972-374-1860 506 Irving, TX. USA Email: david.leon@nokia.com 508 Viktor Varsa 509 Nokia Research Center 510 6000 Connection Drive Phone: 1-972-374-1861 511 Irving, TX. USA Email: viktor.varsa@nokia.com