ded with two new subfields: the instance-id to store a Unified Resource Name (URN) that uniquely identifies the UA and the reg-id to distinguish among flows related to a specific UA when it performs multiple reg- istrations. Ideally, a UA registers multiple times, establishing different flows, C 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security SIP proxy / REGISTER: sip:mydomain.it; keep-crlf SIP/2.0 registrar Via: SIP/2.0/TCP 192.0.2.1;branch=z9hg4bK-bad0ce Max-Forwards: 70 From: Bob <bob@mydomain.it>;tag=d879h76 To: Bob <bob@mydomain.it>; Call-ID:89313s6743433.205 Cseq: 1 REGISTER Supported: Path Contact: <sip:line_one@192.168.0.2>; reg-id=1; A:a I +sip.instance=<"urn:uuid:00000000-0000-100-8000-0A4 Internal network Content-length: 0 FIGURE 12.12 A scenario with a SIP proxy, including SIP registrar. and all the registered Contact fields share the same instance-id while the reg-id vary. UAs have to keep flows alive by periodically sending STUN messages to the proxy if the UDP transport protocol is used. After the regis- tration, UAs send out-of-dialog SIP requests on existing flows; the Contact field in the SIP request should also contain the instance-id used during the registration to uniquely identify the UA. A few scenarios are discussed in the following to provide a better under- standing of the solution. The first scenario (shown in Figure 12.10), which is the simplest, encom- passes a single SIP proxy including a registrar and a UA behind a NAT send- ing to the proxy/registrar the REGISTER message depicted in Figure 12.12, containing instance-id (introduced by the "+sip.instance" string) and reg-id. The registrar will store both the instance-id and the reg-id values together with the URI placed in the Contact field. When it receives an incoming SIP request for the registered URI, instead of resolving it to devise information to forward the request to the UA, the proxy uses the flow initiated by the UA with the REGISTER message. Note that the network address in the regis