Subject: [Sipping] Next steps on draft-elwell-sipping-redirection-reason-01

From: "Elwell, John" <[email-masked]>
Date: Tue, 29 Mar 2005 14:26:04 +0100

At IETF62 discussion on this draft was rather inconclusive. Part of the
confusion was because of two different requirements that the draft attempts
to satisfy.

One requirement is to solve the "3xx ambiguity problem". The problem is that
the repertoire of 3xx responses is insufficient to reflect accurately the
reason for generating a 3xx response. Typically 302 "moved temporarily" is
sent in a variety of circumstances. One example is where a target has
responded 486 "busy here". Another example is where a target has failed to
generate a 2xx response within a given time. A third example is where the
redirection server has responded 302 immediately without having attempted to
forward the request. This last example perhaps fits best to the meaning of
302 ("moved temporarily"), yet 302 in practice is used in other situations
because there is nothing better to send. This problem indirectly leads to
ambiguity in history-info, because history-info (quite rightly) just records
the 3xx response code (e.g., 302) that leads to retargeting.

Possible solutions suggested for this problem:

1. Define new 3xx values to fill gaps.

2. Define the use of a Reason header in a 3xx response and use the Reason
header to convey an existing SIP cause to qualify the 3xx response (e.g., a
302 response containing a Reason header with reason 486 would indicate
redirection because of busy).

3. Define the use of a Reason header in a 3xx response and define a new
namespace of reasons based on call diversion reasons in ITU-T recommendation
Q.732.

4. As 3, but define a brand new namespace populated with values similar to
those in Q.732 but perhaps other values too (basically this is the proposal
in the I-D).

Is there agreement that the "3xx ambiguity problem" is a problem worth
solving?

What are folks' preferences for the solutions identified above? Are there
any strong opinions for or against any of these?

The second problem (for which there was there was little support at the
meeting although there had been support in the past on the mailing list) is
the possible need to provide more accurate information to reflect the reason
for retargeting a request, particularly when retargeted for traditional
reasons such as "forwarding unconditional". This would provide more precise
information on displays at calling and called UAs, more information to
applications, and would map more easily to/from legacy networks, which use
the set of reasons defined in Q.732. Either solution 3 or solution 4 above
would solve this second problem.

Is there any interest in solving this second problem? If so, this might push
us in the direction of solution 3 or 4 for solving the first problem.

John

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Joanne McMillen" <[email-masked]>
Date: Wed, 30 Mar 2005 06:49:52 -0700

All,

I guess I'm rather confused by new discussion that questions the
need to solve the "second problem" - signaling accurate
redirection information. We must have this capability in order for
applications to work properly. Many of us have lived with
this limitation in the past when we could not always signal detailed
redirection information end-2-end. Having said that, it leaves me with
choices 3 and 4. Clearly 3 is better than nothing at all, but
given that we are headed into a realm of new application
possibilities with SIP, I would prefer to see something more robust
in support of that.

Hence, my pick is number 4.

Regards,
Joanne

----- Original Message ----- 
From: Elwell, John
To: [email-masked]
Cc: [email-masked] ; [email-masked]
Sent: Tuesday, March 29, 2005 6:26 AM
Subject: Next steps on draft-elwell-sipping-redirection-reason-01

John

---

From: yaronp <[email-masked]>
Date: Wed, 30 Mar 2005 16:39:55 +0200

I tend to agree with Joanne.

I understood it right, option 4 provides:

1. "3xx ambiguity problem" solution using new values.
2. Q.732 legacy codes are "covered"
3. New, additional codes may be added for future applications.
4. history-info is reach enough.

In this case I think the solution is complete enough.
My vote is for option 4.

Yaron