Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP
RFC 6567

Note: This ballot was opened for revision 09 and is now closed.

(Gonzalo Camarillo) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-11-03 for -)
No email
send info
Although I don't know a use case, it seems unbalanced to me that the 
call control UUI is only present on the INVITE (etc.) method and not
on the corresponding OK. I would have expected that a consumer of such
UUI might need to respond as part of the call control process.

I note that REQ-2 implies that the call controll UUI can be carried on
the OK in response to a BYE.

Might it be helpful to list the methods that can carry the call control
UUI, and for responses say in response to what.

(Stephen Farrell) No Objection

Comment (2011-11-01 for -)
No email
send info
- REQ-11 is very prescriptive about the "one octet
discriminator." Its not clear from the phrasing that the "at
least" also applies to that. I guess it does though.

- I think it'd be good to note that there will be UA security
considerations to be considered - if any old set of bytes can be
attached to an INVITE and then a UA will try to render those,
then that's probably gonna generate new vulnerabilities. 

- Its a pity that the SIP community seem to have given up on e2e
security, which is how I read this. I wonder if there's any way
to make that better...  (maybe rtcweb will do better in this

(Russ Housley) (was Discuss) No Objection

(Pete Resnick) No Objection

(Dan Romascanu) No Objection

(Robert Sparks) (was Discuss) No Objection

(Sean Turner) No Objection