draft-elwell-sipping-redirection-reason-00

Author: John Elwell(john.elwell@siemens.com)

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