no entry is tagged to take the first entry in a further alternative mechanism only re targets are recorded in the history info header although that may be incompatible with sip elements that implement the current rfc4244 in order for a receiving entity to determine the current target it looks up the last history info entry for all alternatives in this embodiment a receiving entity that receives a sip message not containing a history info header can determine the current target from the request uri if the sip entity acts as registrar home proxy for the terminating user it re writes the request uri with the contact address of the registered ua and it may additionally insert a p called party id header field with the previous value of the request uri as described in rfc3455 the alternative embodiments described above can be summarized in the flow diagram of fig1 with the following numbering corresponding to the numbering in the figure 1 a sip message is received at a sip proxy node for example a cscf in an ims network 2 the node re writes the request uri header of the sip message 3 the node checks to see if the request uri rewrite is due to a retarget operation if so then move to step 4 if the retarget is due to a reroute or translation operation then move to step 6 4 where the target header embodiment is used check to see if a target header is already present in the sip message if so then move to step 5 if.