1. IETF 77 MARTINI WG draft-ietf-martini-reqs-02 John Elwell Hadriel Kaplan (editors)

2. History draft-ietf-martini-reqs adopted as WG item following dicussions at interim virtual meetings Combines information from draft-elwell- martini-reqs-01 and draft-kaplan-martini- mixing-problems-00 WGLC on -01 ended 2010-03-05 Issues fixed in draft-ietf-martini-reqs-02draft-ietf-martini-reqs-02 Ready for use in evaluating solutions

3. Recent issues on tracker (1) Some minor defects fixed #2 – remove scalability desirable DES2 – closed as ‘won’t fix’ (DES2 retained) #3 - add req for edge proxy to be able to make identity assertions – closed as ‘won’t fix’ (lack of mailing list support) #17 – add desirable for alignment with existing standards (e.g., ETSI/3GPP) – closed ‘invalid’ (need to be more specific)

4. Recent issues on tracker (2) #16 – add req for extensibility to support any AOR –Closed on grounds that it relates to earlier #6 (which had been closed because of earlier consensus to restrict to E.164-based AORs initially) –Re-opened on basis that only extensibility is sought, not actual support for non-E.164-based AORs –Has been pointed out that the earlier consensus had been made in the knowledge that a more general solution would need to go in a different direction – so requirement would be unachievable

5. Recent issues on tracker (3) #15 – add req for local numbers as AORs –Related to #6 and #16 –Might suffer from same difficulties as #6 and #16 –Numbers can be globally unique, but only through phone-context parameter –Use cases likely to have limited applicability –Question of whether use cases are widespread enough that this needs to be covered in initial deliverable – trying to reduce scope to something manageable –May just work with ‘gin’ solution – but would require effort to analyse it fully

6. Current Problems (for 3GPP/ETSI too) No explicit indicator –Troubleshooting is harder –Some middleboxes really need to know this is different than subscriber Registration Request-URI in the request to the PBX is not well defined, and causes issues PBXs sometimes change the Contact-URI of outbound INVITEs compared with what they Registered –Legal really, but causes authorization policies to reject the request “Wildcard” P-Associated-URI ABNF invalid

7. The Request-URI problem Inserting a Route header isn’t enough… The PBX is not the domain “ssp.com” –Some PBX’s are ok with it (they either ignore the domain, or just accept that it’s their number) –Some PBX’s… not ok If this were “peering”, the Request would be re-targeted to pbx.com If this were “normal” registration-routing, the req-uri would be the registered Contact-URI OriginatorSSPPBX INVITE sip:+12128675309@ssp.com

8. Other problems we’re NOT tackling (leaving “policies” to profiles) Undefined behavior on PAU mismatch –De-register, re-register, ignore? REGISTER response growth –UDP ain’t dead yet (by a long shot) Some SSPs expect PAI to be the explicitly registered AoR, vs. the specific line making the call –It should be the originating AoR identity Some SSPs expect PBX to send PPI, not PAI, because PBX it outside, not trusted