After a longer delay than planned, I want to try to kick off discussions on RFC 4474 issues again. After much activity during IETF71, this is where I think we are, roughly speaking:
There would seem to be 3 main issues: 1) Use of E.164-based SIP URIs within a SIP environment. 2) Use of E.164-based SIP URIs for numbers received from PSTN. 3) The SBC problem. Item 1)(use of E.164-based SIP URI within SIP environment) In fact, there are two angles on this item: 1a) the accuracy of the E.164 number, as characterised by questions such as "is that number assigned to the originator of this request?" This is independent of DTLS-SRTP; 1b) the meaning of the domain part, which does have a bearing on DTLS-SRTP. It means the media are secured as far as that domain, so that if that domain is an organisation you want to talk to, fine, but if it is some intermediary, then you may be concerned. I think there is a certain consensus that we can't do much more than document this problem, but on the other hand we can try to avoid it to some extent by encouraging the use of "email-style" SIP URIs. E.164-based URIs will still be needed, particularly for interworking with PSTN but also in those SIP environments where E.164 numbers are more easily handled (e.g., phones with number-based user interfaces). But perhaps we can explore more the possibility of using the two forms in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) and email-style in From. I know Dan has an interesting straw man on this topic. I will call this topic "Migration from E.164 to email-style SIP URIs" and start a new thread. Item 2) (E.164-based SIP URIs from PSTN) There seems to be some interest in adding some indicator to the URI or to the header field to warn of the limited guarantee of authenticity. I will start a new thread with the title "RFC 4474 and PSTN". Item 3) (SBC traversal) This received relatively little discussion during IETF 71 and on the mailing list. I will start a new thread "RFC 4474 and SBC traversal". There is of course interaction between 1) and 3), in that SBC intervention can lead to re-signing, thereby solving 3) but introducing 1b). As I said above, I will start 3 separate threads to further discuss these three topics. The objective is to have a proposed way forward on the separate topics by the next meeting, in terms of I-Ds, BoF proposals or whatever. So if you want to address those problems, please respond to the appropriate thread. Respond to this email only if you have comments on my interpretation of the set of problems or on the proposed process. John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
