draft-elwell-sipping-redirection-reason-00

1
draft-elwell-sipping-redirection-reason-00

• Author John Elwell(john.elwell_at_siemens.com)

2
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)

3
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)

4
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

5
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

6
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