[martini] Draft Minutes from MARTINI Virtual Interim II

[Bernard Aboba <[e-mail]>]

 

MARTINI WG
Virtual Interim Meeting #2

 

Date: Tuesday Jan 26th, 2009

Time: 10:00 AM: 12:30 PM PST 

Minute takers: 
David Hancock, John Elwell

 

Attendees:

 

Adam
Roach Roach

Adam Roach Uzelac

Alan John Elwellston

Andy Hutton

Bernard Aboba Aboba

Brian Lindsay Lindsay

Rich Shockey

Christain Schmidt

Cullen Jennings Jennings

Dan Romascanu

Dean Willis Willis

Doug Sauders

Ernst Horvath

Hadriel Kaplan Kaplan

James Swan

John Elwell Elwell

Keith Drage Drage

Krisztian Kiss

Mary Barnes

Paul Kyzivat Kyzivat

David Hancock

Spencer
Dawkins Dawkins

 

 

=======================================================================

 

1.  Agenda bashing

No comments.

 

2.  John Elwells
Requirement List

 

Requirement-1:
The mechanism MUST allow the PBX to be
responsible for its AORs and to handle requests to those AORs according to its
rules.

 

Adam Roach: the term “responsible for
domain” is mentioned in RFC3261, and in general it doesn’t allow a non-responsible
proxy to retarget.

 

Paul Kyzivat: Agreed. But if the SSP
network receives a request addressed to the SSP’s domain and identifying an
enterprise user, and the PBX is not reachable, the SSP should be allowed to
retarget the request to voice mail. But if incoming request is addressed to the
enterprise domain then it shouldn’t be allowed to retarget. 

 

Keith Drage: the SSP has a virtual PBX that
is (or represents) the physical PBX. As such it (the SSP) is responsible for
the enterprise domain.

 

Adam Roach: The aspect of domain
responsibility and how it might affect the MARTINI solutions is something new
that hasn’t been fully considered yet.

 

Paul Kyzivat: From a SIP perspective it
makes a difference whether we’re considering only E.164 numbers, or not.

 

Richard Shockey: emphasizes that we’re
really only concerned about telephone numbers.

 

Paul Kyzivat: Things get simplified greatly
if we agree this is only about E.164 numbers. But if we make that
simplification, then the RFC better explicitly state that the scope is limited
to that.

 

Richard Shockey agrees.

 

Dean Willis: this scope issue affects the rest
of our discussion. So this has got to be question number 1.

 

Cullen Jennings: we have to solve the phone
number problem first, and if we do that it is enough for the consumers of this
specification work.

 

Spencer Dawkins: we need to make this
decision on the list, but could we decide to limit it to E.164 numbers for this
call (at least)?

 

Adam Roach: OK with limiting to E.164
numbers, but you have to be able to tell it is an E.164 number by some standard
mechanism. 

 

Spencer Dawkins and Richard Shockey agree.

 

Dean Willis: One way to indicate that URI
contains an E.164 number is to use Tel URIs. 

 

Paul Kyzivat agrees. Tel URIs, solve
problems with From: & To: headers as well.

 

Richard Shockey: what about SIP URI with “user=phone”?


 

Keith Drage: Disagrees with limiting scope
to E.164 number, since it excludes private numbers that may not be E.164
numbers. 

 

Paul Kyzivat: the problem with using a SIP
URI with “user=phone” is that if you don’t own the URI domain then you can’t
look at the user part.

 

Dean Willis: RFC3261 doesn’t allow
registration of TEL URI. But since we’re changing REGISTER: we can change that
too. 

 

Richard Shockey: Let’s narrow the scope to
something solvable.  However, using
TEL URIs is neither necessary nor helpful.  Service providers won’t deploy that. 

 

Hadriel Kaplan: if the SSP receives an
E.164 at SSP domain then there’s no problem. It’s when the request arrives with
the PBX domain that there is an issue.

 

Adam Roach: Richard Shockey (SIPconnect1.1)
has a tight time requirement to solve specific problem, namely to standardize
procedures for support of E.164 numbers. Others in the group have a less time
critical and more general requirement to standardize procedures for any type of
AOR. 

 

Requirements
2,3,4: no comments.

 

Requirement-5:
The mechanism MUST observe SIP backwards
compatibility principles. 

 

Keith Drage: This sounds like a good
requirement, but unfortunately these principles aren’t written down anywhere. 

 

Requirement-6:
The mechanism MUST work in the presence of intermediate "proxies" on
the SSP side of the interface (between the PBX and the SSP's domain proxy),
where those intermediate "proxies" need to be on the path of inbound
requests to the PBX.

 

Someone: If we keep this requirement we
need to nail down the term “proxies”. 

 

Keith Drage: what is the use-case that
requires proxies in enterprise?

 

Paul Kyzivat: There are cases where an
enterprise might want to put an SBC between the PBX and the SP network.

 

Dean Willis: there could be things (like
proxies) between PBX and SP network, and things between enterprise UA and the
PBX.

 

Many responded: the 2nd case is definitely
out-of-scope.

 

Keith Drage: the PBX registration with the
PS network is independent and separate from the enterprise users registering
with the PBX.

 

Dean Willis: there may be some issues with
Outbound.

 

Requirement-8:
The mechanism MUST work without requiring the PBX to publish reachability
information through the DNS.

 

Cullen Jennings: who is the PBX in this
case? This doesn’t sound like a real requirement, it limits solutions. 

 

Bernard Aboba:  I agree with Cullen. 
Dynamic DNS is widely available and inexpensive.  There are some cases (such as putting
an FQDN in a Contact URI) that require DNS resource records to be put in
place.  

 

Hadriel Kaplan: the real issue here is that
the PBX may not have a domain name.

 

Bernard Aboba:  That’s a different requirement. 

 

Requirement-9:
The mechanism MUST work over any existing transport specified for SIP,
including UDP

 

Someone:  SIPconnect 1.1 requires TCP. 

 

Spencer Dawkins: Just to clarify,
SIPconnect 1.1 does allow UDP. It just recommends TCP.

 

Keith Drage: Why is SIPconnect 1.1 content
and timelines driving the solution?

 

Requirement-10:
Do we need any requirement concerning ability

to
check the two sides have matching set of AORs?

 

Brian Lindsay: No, this should be out-of-scope.

 

Adam Roach: Do we have a requirement that
provisioning mismatches can detected?

 

Spencer Dawkins: Question is that should
this be in-scope for MARTINI, or can we use some other SIP mechanism like
reg-event?

 

Brian Lindsay: Maybe there are non-SIP
mechanisms that would be better suited to provide this capability.

 

Keith Drage: This is nice to have, but not
necessarily a must-have MARTINI requirement. 

 

Adam Roach: There are really two separate
problems here...

a) 
how do the SSP and PBX know they have the
same set of enterprise AORs? 

b) 
how do intermediaries know which AORs are
valid for the enterprise (say an SP network edge proxy needs to assert identity
on incoming requests). 

These two could be solved by the same
solution, but they are not the same problem. 

 

Question:
are there any requirements missing?

 

Richard Shockey: Should there be a
requirement for Proxy-Require? i.e. do we require intermediate proxies to
understand this extension?

 

Someone: Pure proxies are somewhat involved
in registration transactions, so we may need to have them understand this. 

 

Keith Drage: Proxies in the path should not
be impacted by the mechanism.

 

Hadriel Kaplan: Can’t we decide this later?
Once we’ve settled on the mechanism, do the right thing so as not to break
things.

 

 

Desirables:
all accepted except for the following…

 

Desirable-2.
The mechanism SHOULD scale to PBXs of several thousand AORs.

 

General comment: there is some ambiguity
about how large a MARTINI-compliant IP-PBX should scale. 

 

Desirable-4.
The mechanism SHOULD allow handling of inbound requests and outbound requests
between SSP and PBX to be as common as possible as with a normal peering
arrangement (RFC 3263 based), as far as the PBX is concerned. 

 

General comment: this last “desirable” is
questionable.

 

3. 
Adam Roach’s Presentation

Slide-2:
Contact Routing vs. Domain Routing

Paul Kyzivat: if Jonathan’s loose-routing
proposal had been accepted, we wouldn’t be worried about overloading REGISTER
with domain routing now.

 

Hadriel Kaplan/Adam Roach/Paul Kyzivat: Does
the reason for rejecting Jonathan’s loose-routing proposal apply to this
MARTINI “shaken-implicit” draft proposal as well? 

 

Hadriel Kaplan: no, Jonathan’s loose route proposal
was rejected in favor of the History-Info solution. 

 

Paul Kyzivat: if we’re going to resurrect
the loose-route solution in MARTINI, then we should consider those issues raised
against Jonathan’s L-R proposal again now.

 

Someone: If scope is limited to E.164
numbers then the usual case is that an incoming request to SSP will contain the
SSP domain. Does this avoid some of the concerns described here? 

 

Hadriel Kaplan: there is still the case where
a remote user uses initiates a call to the enterprise user using the From:
header or Refer-To: header which contains enterprise domain.

 

Slide-3:
Domain Responsibility

 

Paul Kyzivat: The term “responsible for
AOR” is not well defined.

 

Adam Roach: Keith Drage is saying that this
responsibility can span across networks. Anything you can let the PBX do, you
should be able to let the SSP do as well. 

 

Hadriel Kaplan: this is no different than
email: sometimes your email provider is your service provider. 

 

Paul Kyzivat: this could get complicated if
you have multi service providers and one domain name. 

 

Hadriel Kaplan/Paul Kyzivat: agree that maybe
this “multi service provider one domain name” case probably doesn’t make sense.


 

Slide-4:
AORs: To Enumerate or Not to Enumerate

 

Someone: Does reg-event have a way to represent
all the registered AORs? For example, reg-event has no way to say “all AORs in
this domain”. The syntax only supports enumerating each AOR. Keith Drage
thought this case was either supported, or possible to add.Bottom line: if we
choose reg-event as a solution, then we have to include the updates required to
reg-event to make it work. 

 

Brian Lindsay: do intermediaries really
need to know the list of AORs? P-CSCFs need to know: but they have a way. If
all intermediaries are on the SSP side, then whatever mechanism is used doesn’t
appear on the interface and is therefore out-of-scope w.r.t. MARTINI.  

 

Keith Drage: agrees.  

 

John Elwell: The concept that the P-CSCF
knows the list of AORs assigned to the IP-PBX, and uses this information to
assert the identity of the calling enterprise user is flawed anyway; e.g., consider
the case where a call from a user outside the enterprise arrives at the IP-PBX
via a “tie-line” trunk? 

 

Slide-5:
Multiple AORs : Implicit or Explicit?

 

 

Someone: The
issue around having the SIP-PBX sending the regular-expression up to the SSP,
-- isn’t it too complex to expect to work? i.e. it’s sufficiently complex that
there’s a good chance the PBX vendor will not implement it well.

 

Hadriel Kaplan: point of there would only
be one [e-mail]

 

Slide-6:
Contacts: To Map or Not To Map?

 

Slide-7:
REGISTER Applied to Multiple Humans

No comments recorded.

 

Slide-8:
Transport: Is UDP a requirement?

This topic already covered during review of
John Elwell’s requirement list.

 

Cullen Jennings: once we figure out the
solution: thinks UDP won’t be an issue. 

 

4. 
Keith Drage’s Presentation

Slide-3:
Relationship of identities

Someone: What do the different boxes
represent? 

 

Keith Drage: A Private User Identity is
specific to your phone/CPE, while a Public User Identity your AOR. 

 

Slide-5:
Business trunking (release 8)

Cullen Jennings: Is it true, as some people
have asserted, that there is a violation of SIP RFCs (e.g., wildcard Public
User Identity breaks URI syntax)? 

 

Keith Drage: there may be an issue, but
haven’t looked.

 

5. 
Dean Willis’s Presentation

This presentation problem identifies a
problem with connection re-use where there are multiple domains using a single
route. 

 

Slide-3:
Alternate Topology

Paul Kyzivat: is this really a problem?
Couldn’t this be accomplished simply by establishing two flows?

 

Hadriel Kaplan: wasn’t the problem with
connection reuse that the SSP had no way to authenticate the PBX
(connection-reuse was actually for proxy-to-proxy)? But we don’t have that
problem because the SSP can authenticate the PBX using SIP Digest. 

 

Cullen Jennings: what is the shared secret?
Is it something for a single user, or for a whole domain? What exactly is authenticated
by that shared-secret? 

 

Hadriel Kaplan: it would authenticate all
the PBX AORs. 

 

Cullen Jennings: traditionally it would
only authenticating the AOR being registered. 

 

Hadriel Kaplan: if the SP network receives
a request addressed to the target enterprise domain, then the SP network simply
loose-routes the request and it should arrive at the correct enterprise user.
If the SP network receives a request addressed to the SAP domain but destined
for an enterprise user, then the SP network must make a decision as to which enterprise
domain to retarget to. 

 

Paul Kyzivat: this could all be driven by
provisioning, where if one thing happens then provisioning says this other
thing happens, etc. So on the one hand there should be no problem, but on the
other hand, it’s not clear.

 

Dean Willis: we just need to satisfy
ourselves that the connection-reuse issues identified in section 9.3 of the
re-use draft don’t apply to this MARTINI case as well.

 

6. 
Hums

Bernard Aboba: should initial focus be to
solve the E.164 problem first? I.e., agree to deliver on a milestone to limit
to E.164?  Should we describe the
HUM as restricting to tel URIs, which would also support private URIs. 

 

Brian Lindsay: should we limit scope to
phone numbers? 

 

Adam Roach: no, since telephone numbers
have are digit strings. For this to work the user part has to be a unique key. 

 

Paul Kyzivat: one of the contexts for local
tel URIs is domain name: and so if we allow local Tel URIs we still have the
domain issue. 

 

Do we do a point solution for E.164, and then
tackle the more general problem?

 

Paul Kyzivat: there are some common
non-E.164 numbers like 911: would these be precluded if we limited the scope to
“E.164-only”? 

 

Cullen Jennings: No, it wouldn’t. The
E.164-limitration applies to enterprise AORs, and “911” would never be assigned
to an IP-PBX. 

 

Cullen Jennings: should the hum be reworded
to say that the PBX should only register E.164 public user IDs? Reason being: call
xfer, which requires support of some non-E.164 GRUU-like URI, still needs to
work.

 

Bernard Aboba: what are next-steps, to be
completed by the next meeting? 

 

Action Item to Dean Willis & Adam Roach
to bring the E.164 scope issue to the list.