> > 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.
Right. How about we list all kinds of possible errors in new version and specify how the intermediate peers do when such kinds of errors are happening? >I think this is how the draft is now.. Sorry. When I read through the draft, I don't find descrptions in RELOAD-4 which addressed errors happening on the intermediate peer. All the error codes seems pointing to the errors processed by the responsible peer. Am I missing something? Regards! JiangXingFeng > 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/p2psip > >> > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
