First, I have revised the E.164 problem statement draft, which had expired. The only changes are a clarification to the introduction concerning E.164 number formats and an addition to the sentence on number portability in 2.1: http://www.ietf.org/internet-drafts/draft-elwell-sip-e164-problem-statem ent-01.txt
Second, I have revised the e2e identity important draft, just to capture (near the end of section 2.4), a set of arguments Hadriel gave for not re-signing at intermediaries: http://www.ietf.org/internet-drafts/draft-elwell-sip-e2e-identity-import ant-01.txt Third, a reminder that there were thoughts expressed in Dublin that we should capture in a draft considerations about how a UA should handle received identity information. A first attempt at this is in: http://www.ietf.org/internet-drafts/draft-elwell-sip-identity-handling-u a-00.txt Also there are other drafts on the subject from Hadriel Kaplan, Kai Fischer, Dan Wing and others, mostly expired. Finally, where do we stand on this whole topic? It is known that certain SIP intermediaries (B2BUAs, SBCs) break RFC 4474 signatures. In some cases the reasons for such modification are considered doubtful, but in other cases there may be justification. During the Dublin session we focused on a particular problem caused by B2BUAs/SBCs, that of media steering. This is known to break RFC 4474 signatures (since it involves changing IP addresses and ports in SDP). There was no conclusion as to whether this is indeed a justified modification, whether it is a problem that needs solving, and what to do about it. It was also asked whether there are other potentially justified behaviours of intermediaries that break RFC 4474 signatures. One possible candidate is codec selection, whereby an intermediary removes from an SDP offer those codecs that fall outside policy or for which bandwidth is not currently available. Another possible candidate is topology hiding, by changing Call-Id values to hide information. Yet another possible candidate is changing Cseq values, to compensate for 3PCC actions. I think we need to get a complete list of such behaviours and assess to what extent they are justified (and therefore the importance of finding a solution to the problems that arise). So I would welcome more discussion on the subject prior to Minneapolis. 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
