Subject: [Sipping] RE: [Sip] Requirements on Reason information. New I-D

From: "Eric Burger" <[email-masked]>
Date: Tue, 19 Mar 2002 10:36:55 -0500

This is why we have SIPPING: the REASON header would be a sensible way of
solving the issues raised by Gonzalo in his draft.  In addition, it would,
with some modifications, also solve the issues raised in
draft-watson-sipping-req-history-00.txt.

I would propose that the requirements raised in
draft-camarillo-sipping-reason-00.txt get folded into a revision of
draft-watson-sipping-req-history.

Correct me if I'm wrong, but I don't think
draft-schulzrinne-sip-reason-01.txt, as it stands today, addresses the
history part of the SIPPING requirements.  The draft is silent on this
point, but it looks like the SIP entity generating the message with the
Reason header inserts it only for *its* operation.  That is, it explains why
that particular entity failed.  Said differently, it looks to me that there
will be only one Reason header in a SIP message.

If we can carry and identify the source of the Reason headers, like we do
for Via or SMTP does for Received-By, then this header can satisfy both
camarillo-sipping-reason's and watson-sipping-req-history's requirements.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Gonzalo
Camarillo
Sent: Tuesday, March 19, 2002 3:01 AM
To: sip; Brian Rosenberg (EUS); Dean Willis; Joerg Ott; [email-masked]
Cc: Henning Schulzrinne; [email-masked]
Subject: [Sip] Requirements on Reason information. New I-D

Chairmen,

I presented the Reason header field draft today in the SIP WG meeting:
http://search.ietf.org/internet-drafts/draft-schulzrinne-sip-reason-01.txt

Some folks considered that the requirements for this work were not clear
enough, so I was asked by the chairmen to write a set of requirements.
We agreed that there was no need to wait for the next IETF meeting in
order to progress such a requirements draft. Discussions in the mailing
list were encouraged.

I have put together an I-D with those requirements.

http://standards.ericsson.net/gonzalo/draft-camarillo-sipping-reason-00.txt

I would like to know if these requirements are what you expected or if,
on the other hand, you wanted something else...

I intend to submit this draft, including the comments I may receive, on
Monday.

Thanks,

Gonzalo
--
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027
USA                              [email-masked]

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

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Mar 2002 11:58:13 -0500

Gonzalo,

Glad to see this. I would like to offer an added use-case:

There is often value in knowing why a reINVITE has been sent,
because the target may need to take different actions depending
on the reason.

For instance, consider a reINVITE that is fully consistent
with the prior invite - same SDP. This might be simply a request
to refresh the session, especially if session timers are in effect.
In this case, the target ought to simply return the same answer
it did the previous time.

However another situation may have prompted this reinvite.
It may be that the sender has detected a problem with the
session - for instance it may be getting errors sending
media. It still wants to do the same thing and so has nothing
to change in its own SDP, but would like the target to do
something to correct its end. This is especially important if
the target is itself a B2BUA.

Another example is in use of reINVITE as a part of call transfers,
expecially with B2BUAs. For instance, a 3pcc controller may be
in the process of tranferring an existing UA to a new UA. In this
case the usual call flows involve sending a reINVITE with no SDP.
In this case it is desirable that the target return SDP containing
all the media & codecs that it is capable of supporting, whereas
in other cases it is desired that only the media and codecs currently
in use be returned.

Reason codes could clarify each of these cases.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 20 Mar 2002 05:51:22 +0200

Hi Eric,

> camarillo-sipping-reason's and watson-sipping-req-history's requirements.

In the SIP WG meeting Dave Oran explicitly asked to leave out of this
work any identification stuff, and there was rough (actually total)
consensus about it. Therefore, I do not think it is appropriate to try
to pull it in at this point of time.

Regards,

Gonzalo