Completion of Calls for the Session Initiation Protocol (SIP)
RFC 6910
Note: This ballot was opened for revision 18 and is now closed.
Barry Leiba (was Discuss) Yes
Comment (2013-02-11)
No email
send info
send info
This is a well-written document specifying a useful protocol; thanks. The -19 version addresses all the issues and questions I had. Because there was a gap in IANA's action list on their review -- a gap which has since been clarified with them -- I urge the authors to be especially careful to review IANA's final actions after the document is approved, and be sure that all five actions are correct.
(Robert Sparks) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Benoît Claise) No Objection
Comment (2013-01-06 for -18)
No email
send info
send info
Two very minor points. Acronym: while UA, UAC, and UAS might be known in the SIP world, I had to look up the AOR acronym. 4.4. Differences from SS7 SIP call completion differs in some ways from the CCBS and CCNR features of SS7 (which is used in the PSTN). For ease of understanding, we enumerate some of the differences here. From the 3 following paragraphs, it's not too clear where the differences are since don't speak about SS7 at all.
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) No Objection
Comment (2013-01-07 for -18)
No email
send info
send info
Only the first of these is (maybe) really a deal: - I wondered about the duration of state here. E.g. if the callee's monitor could get a caller's UA to maintain state for a long time then the callee could track the caller's presence. I think you should note that in the security considerations. Or maybe it'd be better if the caller's agent had to have some kind of limit after which subscriptions are definitely terminated. (You do recommend an hour, but that's not quite the same.) - I wondered about authentication here and the possibility to get someone else billed for something. Does CC open up any new ways to do that? Say if hop-by-hop authentication is in use, but someone uses a credential that gets revoked - could CC happening after the revocation incur costs on someone wrongly? I suspect these are all existing issues or trivial corner cases that don't warrant a mention but just wanted to check. - In section 9 the term "notifier" confused me. I guess it'd be clear to SIP folks, but it might be good to say here who that is somewhere in section 3. - 6.2, typo: s/SHOULD presented/SHOULD be presented/? - 9.4, typo: s/after certain/after a certain/? - 11, typo: s/DoD/DoS/
(Brian Haberman) No Objection
Comment (2013-01-03 for -18)
No email
send info
send info
I support Barry's DISCUSS point related to the IANA Considerations.
(Russ Housley) No Objection
(Martin Stiemerling) No Objection
(Sean Turner) No Objection
Comment (2013-01-09 for -18)
No email
send info
send info
I was worried that a caller could dominate a callee's call completion queue, but Robert's convinced me it's probably not that big of a deal. But, what about adding some text about repeated call cases and that agents shouldn't subscribe again when they already have a subscription. (or is it in there and I missed it)