[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [P2PSIP] 回复: Error Reason Phrase
Yes, I agree, I think an intermediate node that has or detects an
error will needs to return an error. For example if a node forwarding
detects that a TTL has been exceeded due to some loop condition, it
should return an error. I think this is how the drafFrom p2psip-bounces at ietf.org Sun Jul 20 12:00:26 2008
Return-Path: <p2psip-bounces at ietf.org>
X-Original-To: p2psip-archive at optimus.ietf.org
Delivered-To: ietfarch-p2psip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 1059D3A6AAD;
Sun, 20 Jul 2008 12:00:26 -0700 (PDT)
X-Original-To: p2psip at core3.amsl.com
Delivered-To: p2psip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9CF803A6A97
for <p2psip at core3.amsl.com>; Sun, 20 Jul 2008 12:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.353
X-Spam-Level:
X-Spam-Status: No, score=-106.353 tagged_above=-999 required=5
tests=[AWL=-0.206, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3,
RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id HtmbxIQQFXBE for <p2psip at core3.amsl.com>;
Sun, 20 Jul 2008 12:00:23 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117])
by core3.amsl.com (Postfix) with ESMTP id B6FBD3A697E
for <p2psip at ietf.org>; Sun, 20 Jul 2008 12:00:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,219,1215388800"; d="scan'208";a="129193528"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
by sj-iport-6.cisco.com with ESMTP; 20 Jul 2008 19:00:55 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6KJ0tGS014197;
Sun, 20 Jul 2008 12:00:55 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
by sj-core-2.cisco.com (8.13.8/8.13.8) with SMTP id m6KJ0tAi001083;
Sun, 20 Jul 2008 19:00:55 GMT
From: Cullen Jennings <fluffy at cisco.com>
To: jiangxingfeng 36340 <jiang.x.f at huawei.com>
In-Reply-To: <f95687de3bc.3bcf95687de at huawei.com>
Impp: xmpp:cullenfluffyjennings at jabber.org
References: <CD7D2853-C43A-41AC-B890-F76329C426C1 at cisco.com>
<f95687de3bc.3bcf95687de at huawei.com>
Message-Id: <52B78DE9-0FB9-4A70-BF29-D38A55CFC0F5 at cisco.com>
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Sun, 20 Jul 2008 12:00:44 -0700
X-Mailer: Apple Mail (2.928.1)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1804; t=1216580455;
x=1217444455; c=relaxed/simple; s=sjdkim1004;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=fluffy at cisco.com;
z=From:=20Cullen=20Jennings=20<fluffy at cisco.com>
|Subject:=20=3D?UTF-8?Q?Re=3A_=3DE5=3D9B=3D9E=3DE5=3DA4=3D8
D=3A[P2PSIP]_Error_Reason_Phrase?=3D |Sender:=20;
bh=ANfYOHJNSIUS0tbZSLldLcvFz0f1UapwMXAAqZOpI6w=;
b=XZG40q3/av3JG3mEgId58JJwk690ZSWZFjygr0CuB7GpUl1lN9qvZ2+EX2
50QmzdxifYxRfNtncTmLMPd0dsv9ItUAEHDj723p2QETU3aW5OdpqRxc5nIh
slzDd+M0tz6tn903qLP5FZXhmXwi58QrFamWUx0vWMeUES8+gw5z0=;
Authentication-Results: sj-dkim-1; header.From=fluffy at cisco.com; dkim=pass (
sig from cisco.com/sjdkim1004 verified; );
Cc: P2PSIP WG <p2psip at ietf.org>
Subject: Re: [P2PSIP] =?utf-8?b?5Zue5aSNOiBFcnJvciBSZWFzb24gUGhyYXNl?=
X-BeenThere: p2psip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2psip>,
<mailto:p2psip-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip at ietf.org>
List-Help: <mailto:p2psip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>,
<mailto:p2psip-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: p2psip-bounces at ietf.org
Errors-To: p2psip-bounces at ietf.org
Yes, I agree, I think an intermediate node that has or detects an
error will needs to return an error. For example if a node forwarding
detects that a TTL has been exceeded due to some loop condition, it
should return an error. I think this is how the draft is nowt is now.
Cullen
On Jul 16, 2008, at 6:38 PM, jiangxingfeng 36340 wrote:
Hi:
As for error, there are two kinds error in the P2PSIP transaction.
One is what happened on the responsible peer, such as no resource,
etc. The other is what happened while intermediate peers processed
the message, such as hop-by-hop error, no reverse connection, etc.
So a open issue in my mind is whether the peer protocol tries to
catch the latter error. IMHO, it may be helpful in debugging the
system.
Regards!
JiangXingFeng
In section 6.2.3.1, the error response have numeric code, an
"reason
phrase" which is a text string that for any given number code
SHOULD
have it value set to a specific string. There is also an extra
error_info string that can contain extra information to help debut
the
problem. From my point of view, I see absolutely zero value in the
extra "reason_phrase" string and am wondering if we can just get
rid
of it. The protocol for historic reasons also mapped the error
codes
onto http error and error classes (i.e. 3xx, 4xx errors etc).
However,
the protocol does not use any of this anywhere and I worry it
causes
more confusion that it solves. We should consider moving the error
codes just to be sequentially allocated numbers.
_______________________________________________
P2PSIP mailing list
P2PSIP at ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
P2PSIP at ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
.
Cullen
On Jul 16, 2008, at 6:38 PM, jiangxingfeng 36340 wrote:
Hi:
As for error, there are two kinds error in the P2PSIP transaction.
One is what happened on the responsible peer, such as no resource,
etc. The other is what happened while intermediate peers processed
the message, such as hop-by-hop error, no reverse connection, etc.
So a open issue in my mind is whether the peer protocol tries to
catch the latter error. IMHO, it may be helpful in debugging the
system.
Regards!
JiangXingFeng
In section 6.2.3.1, the error response have numeric code, an
"reason
phrase" which is a text string that for any given number code
SHOULD
have it value set to a specific string. There is also an extra
error_info string that can contain extra information to help debut
the
problem. From my point of view, I see absolutely zero value in the
extra "reason_phrase" string and am wondering if we can just get
rid
of it. The protocol for historic reasons also mapped the error
codes
onto http error and error classes (i.e. 3xx, 4xx errors etc).
However,
the protocol does not use any of this anywhere and I worry it
causes
more confusion that it solves. We should consider moving the error
codes just to be sequentially allocated numbers.
_______________________________________________
P2PSIP mailing list
P2PSIP at ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
P2PSIP at ietf.org
https://www.ietf.org/mailman/listinfo/p2psip