Subject: [Sip] Comments on draft-schulzrinne-sip-reason-00.txt

From: "Cullen Jennings" <[email-masked]>
Date: Sat, 5 Jan 2002 12:22:23 -0800

Do we really need the reason code or is the cause code enough?

Do we need to know the identify (URI or something) of the person who caused
the generation of the header? For example, If a proxy sent an forked an
invite with an URI of sip:[email-masked] and got back a 600 then decided
to cancel the other branches, I think it might be useful to have the
"sip:[email-masked]" in the reason header.

Embedding Q.850 stuff into the SIP protocols seems like a bad idea. If we
need to add a few new SIP response codes to be able to create a richer ISDN
to SIP mapping that is fine but I'm not sure I see why Q.850 codes are
needed.

I assume that a message can only have one reason header.

Would a generic solution to the call history problem also be able to meet
the requirements that this solves?

_______________________________________________
Sip mailing list  http://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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 05 Jan 2002 20:12:33 -0500

Thanks for your feedback.

> Do we really need the reason code or is the cause code enough?

The idea is to have one code that an implementation can look at without
having to know protocol details, e.g., about ISUP.

> "sip:[email-masked]" in the reason header.

Interesting idea, but I'm a bit concerned about having this be uniquely
defined. In most cases, this would be the same as the original request
URI in any event.

> to SIP mapping that is fine but I'm not sure I see why Q.850 codes are

This is effectively just carrying the information around. Since there's
the reason code, the receiver doesn't have to interpret it, but could.
This is similar to what happens when you get back an SMTP failure
indication that was actually caused by some X.400 mail system. The SMTP
message contains an indication of the original error message so that an
X.400 expert can look at it and interpret it.

Maybe it would be appropriate to say that the protocol can carry any
numeric "foreign" error code.

The problem with translation is that while this might work for Q.850,
the next protocol that comes along will have some other set, so the
translation will often be many-to-one, thus losing information. (For
example, one could imagine having to carry back H.323 or Avvid codes.)

I'm not wedded to the idea of carrying around "foreign" error codes, so
I would welcome other feedback.

> I assume that a message can only have one reason header.

Yes; I will add a note to this effect.

> the requirements that this solves?

Possibly. Maybe once a concrete proposal has been worked out, we'll
know.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 06 Jan 2002 14:14:38 +0200

Hi,

>I would welcome other feedback.

I also wonder if it's really needed. The ISUP/SIP mapping draft defines
how SIP reason codes are mapped into Q.850 when received in a RESPONSE
message. Couldn't the same mechanism be used to map the SIP reason code
when received in a REQUEST message?

Of course, the receiver could ignore the cause code and map the reason
code according to the ISUP/SIP mapping draft (or according to whatever
specification) anyway... 

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 06 Jan 2002 13:18:51 -0500

Christer Holmberg wrote:

> when received in a REQUEST message?

Is the mapping one-to-one? One potential problem is that the reason
codes in the Reason header would each map to several Q.850 codes, thus
losing information.

> code according to the ISUP/SIP mapping draft (or according to whatever

Indeed; the cause code is optional, after all.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 07 Jan 2002 08:02:54 +0200

Hi,

>codes in the Reason header would each map to several Q.850 codes, thus

I guess that's something we should look into.

Otherwise, one could argue that we should allow the reason code to
RESPONSE messages too...
 
Regards,

Christer Holmberg
Ericsson Finland