There may have been a mailer problem with the first sending of this report to the Sipping mailing list. ====================================================================== RFC3398, "ISDN User Part (ISUP) to SIP Mapping" Source of RFC: sipping (rai) Errata ID: 2580 Status: Reported Type: Technical Reported By: Stephen James Date Reported: 2010-10-19 Section 8.1.3 says: Item 6. The gateway also sends a CANCEL message to the SIP node to terminate any initiation attempts. It should say: Drop this statement. Notes: No CANCEL is sent on INVITE transaction timeout. This is per 3261 "If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request." ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update Section 8.1.3 item 6 should be updated to "The gateway also sends a CANCEL message to the SIP node to terminate the initiation attempt if a provisional response has been received." The situation illustrated in section 8.1.3 does not distinguish the "provisional response received" case from the "provisional response not received" case, so the commentary should cover both cases. (The specific example diagrammed shows the "no provisional response received" case.) A similar change should be made to section 8.1.4 item 7, "The REL will trigger a CANCEL request to the SIP node if a provisional response has been received." A similar change should be made to section 8.1.7 item 7, "Upon receipt of a REL message before an INVITE final response, the gateway will send a CANCEL towards the SIP node if a provisional response has been received. Since a reader familiar with SIP will know the rules for sending CANCEL, this correction is not crucial for proper implementation of the RFC, so I am recommending that it be held for document update. ====================================================================== RFC5479, "Requirements and Analysis of Media Security Management Protocols" Source of RFC: sip (rai) Errata ID: 2121 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2010-04-05 Section 5.1 - 5.3 says: Notes: Sections 5.1 through 5.3 use unexpected irregular, non-uniform indentation in hanging lists; this is accompanied by dangling hyphens in 5.2 ( s/third- party/third-party/ and s/crypto- agility/crypto-agility/ !). (Keep for update!) third- party ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update ====================================================================== RFC5479, "Requirements and Analysis of Media Security Management Protocols" Source of RFC: sip (rai) Errata ID: 2122 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2010-04-05 Section App. A says: [[ second-to-last paragraph, on mid-page 24: ]] Related to SRTP's characteristics is a goal that any SRTP keying | mechanism to also be efficient and not cause additional call setup delay. It should say: Related to SRTP's characteristics is a goal that any SRTP keying | mechanism also be efficient and not cause additional call setup delay. Notes: Rationale: language/grammar improvement -- keep for update! ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update ====================================================================== Dale _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
