draft-elwell-sipping- redirection-reason-00 Author: John Elwell

Problem 1 RFC3261 does not distinguish between normal routing and retargeting Problem if done by proxy or UAC as result of 3xx from redirect server –ambiguity of 3xx response –proxy or UAC does not know whether to add History- Info entry Example –Redirect server sends 302 Moved Temporarily –Acts as instruction to upstream proxy or UAC to redirect –But does not convey reason for redirection (e.g., retargeting because of busy)

Problem 2 draft-ietf-sip-history-info can provide Reason header in history-info entry indicating reason why previous target failed, but: –Limited at present to SIP response codes and Q.850 causes –Unable to convey reason why the new target was chosen (e.g., call forwarding immediate, call forwarding busy, hunt group resolution)

Analysis The two problems lead to a need to convey more precise reason information both in a 3xx response and in a History- Info entry

Possible solutions Solution 1 – add new protocol value to Reason header –Impact on History-Info draft – would need to copy from 3xx response into History-Info header –Or is copying Reason header desirable anyway? Solution 2 - add new redirection-reason URI parameter for use in Contact header –No impact on History-Info draft (since URI copied anyway) –Not strictly in accordance with the principle of URI parameters Solution 3 – define new 3xx response codes

Question for SIPPING group What is preferred solution? –Solution 1 – add new protocol value to Reason header –Solution 2 - add new redirection-reason URI parameter for use in Contact header –Solution 3 – new 3xx response codes