IETF 77 MARTINI WG draft-ietf-martini-reqs-02

1
IETF 77 MARTINI WGdraft-ietf-martini-reqs-02

• John ElwellHadriel Kaplan (editors)

2
History

• draft-ietf-martini-reqs adopted as WG item
  following dicussions at interim virtual meetings
• Combines information from draft-elwell-martini-req
  s-01 and draft-kaplan-martini-mixing-problems-00
• WGLC on -01 ended 2010-03-05
• Issues fixed in draft-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 wont fix (DES2 retained)
• 3 - add req for edge proxy to be able to make
  identity assertions closed as wont 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
Originator
SSP
PBX
INVITEsip12128675309_at_ssp.com
INVITEsip12128675309_at_ssp.com

• Inserting a Route header isnt enough
• The PBX is not the domain ssp.com
• Some PBXs are ok with it (they either ignore the
  domain, or just accept that its their number)
• Some PBXs 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

8
Other problems were NOT tackling(leaving
policies to profiles)

• Undefined behavior on PAU mismatch
• De-register, re-register, ignore?
• REGISTER response growth
• UDP aint 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