aniel Bowditch <sip:bowditch321@capetown.org> From: Nathaniel Bowditch <sip:bowditch321@capetown.org> tag=887865 Call-ID: 54-34-19-87-34-ar-gr CSeq: 3 REGISTER Contact: <sip:nat@128.5.2.1> Content-Length: 0 and the second registration message with the roaming URI would be: REGISTER sip:registrar.salem.ma.us SIP/2.0 Via: SIP/2.0/TL 128.5.2.1:5060;branch=z9hG4bK1834 Max-Forwards: 70 To: Nathaniel Bowditch <sip:n.bowditch@salem.ma.us> From: Nathaniel Bowditch <sip:n.bowditch@salem.ma.us>;tag=344231 Call-ID: 152-45-N-32-23-W3-45-43-12 CSeq: 6421 REGISTER Contact: <sip:bowditch321@capetown.org> Content-Length: 0 The first INVITE that is depicted in Figure 9.2 would be sent to sip:n.bowditch@salem.ma.us;t the second INVITE would be sent to sip:bowditch321@capetown.org and the third INVITE would be SIP: Understanding the Session Initiation Protocol Visited Bowditch registrar/ registrar/ Laplace proxy proxy DHCP Request DHCP ACK REGISTER 200 OK REGISTER 200 OK INVITE 302 Moved INVITE INVITE 200 OK 200 OK Media session Figure 9.2 Precall mobility using SIP REGISTER. sent to sip nat@128.5 2 . 1, which reaches Bowditch and allows the ses- sion to be established. Both registrations would need to be periodically refreshed. A disadvantage of this approach that SIP does not currently have a means to obtain a local URI. This would have to be done using a non-SIP method such as a Web page sign-up, which would be coupled with the proper authentication, authorization, and accounting mechanisms. An optimization of this is for the local registrar to forward the registration information on the roaming user agent back to the home registrar. This has been proposed in the IETF [4] but has yet to be adopted or standardized. No Wireless and 3GPP changes to SIP messages are required, just a convention adopted by registrars to recognize a roaming registration and take the appropriate action. It is possible that these conventions may become standardized if the authentication and accounting systems needed to properly process such registrations