[VIPR] Minutes for 2011/09/23 conference call

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

VIPR Design Team conference call on Friday September 23rd, from 9:05am to 9:54am
PST.

o Attendees:
  Mary Barnes
  Daryl Malas
  Hakim Mehmood
  Muthu Arul Mozhi Perumal (microphone was not working)
  Jon Peterson
  Marc Petit-Huguenin
  Michael Procter
  John Ward

o Regrets:
  Dean Willis

o Agenda

- - Introduction (5 min)
- - PSTN origination over SIP (5 min)
- - PSTN termination over SIP (10 min)
- - RELOAD registration (5 min)
- - PVP privacy (10 min)
- - PVP method priority and registration (10 min)
- - PVP method entropy (10 min)
- - Replacement ticket by client certificate (10 min)
- - Ticket renewal (10 min)

o Minutes

- - Introduction

Marc: A new framework document will document VIPR from a more abstract point of
view, and will only be about interactions between VIPR domains, and we'll work
on interactions inside a domain later.

[no comments]

- - PSTN

Marc: Current documents talks only about PSTN calls, but including SMS, H.320,
Faxes and modems would permit to have more validation options.

Mary: Good idea but should keep that for a next phase. We do not want to out
design, but some things are specific.

Hakim: Yes SMS is different but voice, video and fax should not be processed
differently.

Michael: Agree that it could gives us more options, but we should not at this stage.

Marc: We should separate the validation methods from the PSTN access.  The
proposal is to say that all these kind of access can be used, and we keep the
definition of the validation methods for later.

- - PSTN over SIP

Marc: The drafts talk about direct connection to the PSTN but in reality
enterprises are using SIP trunks and VoIP providers do not always have PSTN
gateways under their control.

Hakim: Are you distinguishing between IP PSTN and TDM PSTN?

Marc: Yes

Jon: Security implications are really dire as routing is different from the PSTN.

Hakim: IP PSTN uses the same routing than say SS7.

John: We bypass the PSTN all the time.

Hakim: Yes IP PSTN is different from peering.

Jon: Do not prevent using it, but this is something that should be noted.

Marc: It's a good idea to separate the cases and have a strong security section.

Marc:  Moving to PSTN over SIP origination.  For an outgoing call to the PSTN
from a VIPR domain to another VIPR domain, you can have two originating VCR and
one terminating VCR.  The text added says that the terminating VCR should not be
removed until the end of the 24 hours [should have been 48 hours] period, i.e an
outgoing call going through two domains and so two PVP transactions will be
started against the same terminating VCR.

Jon: Important to note that this is not going to achieve what VIPR is supposed
to do, which is getting one endpoint connecting to an endpoint so that advanced
features like video work.  It will save cost, but you do not need VIPR to do that.

Marc:  There is nothing that prevents a VIPR domain to put a video component in
the call to the PSTN.

Jon:  Not what I meant.  If not directly connected to the endpoint, sending a
VCR is defeating the purpose of VIPR.

Hakim: Yes.  If you did not store, then you do not send an originating VCR.

Marc: Yes, the two domains claims ownership of the number.

Marc: Next topic is the opposite case, two domains on an incoming call from the
PSTN sends a terminating VCR, so the originating side will try both, and will
receive two routes.  The proposal is to not choose and use forking.

Hakim: Perhaps using the timestamp to find which one is the closest to the user,
and prefer this route.

Jon: Will probably be worst if lot of people advertize route to a number.

Michael: Routing can change with the time of day, which the user could not be aware.

Jon:  Perhaps it is a requirement for an additional secret that we know only the
equipment possess.

Daryl: Perhaps only the endpoint should participate.

Jon:  But there is uses cases that won't work, we want to be liberal here. PSTN
routing provides us a very important property, but this could not be the only
property we care about.

Daryl: There is another variant with hosted IP PBX vs IP PBX at the customer
premise.

Michael: I would be very surprised to see merged call.

Daryl:  I am concerned that this issue will come up again, would anyone be
willing to take an action item?

Marc:  We need to decide if we want to talk only about VIPR domain directly
connected to the Internet [should have been PSTN] and put the IP PSTN in an
extension, or not.

Hakim: But you would have the same problem if you intermediate proxy does a store.

Marc: In my opinion we should fix the problem because we want to be as inclusive
as possible.

Hakim: Someone participating could do store at any intermediate level.

Marc: Right, and even for a direct PSTN connection, there is nothing that
prevent the PSTN provider to use VoIP behind the scene.

Michael: Yes, a reasonable thing to do.

Jon: The fundamental question is what we try to achieve with VIPR.  If we see it
as a way to circumvent the PSTN, I do not think that VIPR is very interesting.
If you are not providing enhanced features like video to the end-user you should
not be participating in VIPR.

Michael:  That is certainly what I am interested in, but other providers may use
it as a way to reduce cost.

Hakim: We are trying to solve a generic problem.

Daryl: Closest route does not means best route.

John: You want to know the secondary route.

Hakim: Yes from a priority standpoint.

Daryl: Priority means that you will always chose the same route, but how to you
make that choice?

John:  Shouldn't you advertize the capabilities supported by the endpoint?

Jon: Can be done done at the SIP level or at the VIPR level.

Daryl: I agree that we need to enable capabilities, but is there any security
issue?  Toll bypass is not a driving factor, but it should be assumed that it
will be a selling point.

Hakim: Going back to security, everything is untrusted until the validation.
Putting the endpoint capabilities in VIPR is somewhat counter to the original
concept.

Jon: Yes, after the validation succeeds, how do you decide which route, perhaps
based on capabilities.

Daryl: There is ways to do this at the SIP level.

Hakim & Michael:  This can be done with OPTIONS.

Jon: Yes but also at the SDP level.

Daryl: But you do this at the phone level.

Jon: Can be done at multiple layers.

Daryl: So we can actually based on the response from the fork choose the best route.

Jon: Yes.

Hakim: Or do a preINVITE call.

Jon: OPTIONS is slightly different.

Hakim: One of the option is to outsource the route choice to the application.

Daryl: Two questions: VIPR or SIP? or both?

Jon: Multiple routes at this stage is undesirable.  It is a corner case.

Marc: We do not know how VIPR will be deployed.

Jon: If the result of VIPR is toll bypass, then we failed. So an intermediary
that does not support enhanced media should not participate in VIPR.

Daryl & Hakim: Agreed

Mary: We need to add some text about this.

Daryl: We should clearly specify state where VIPR should be best use.

Mary: Or been very specific about the intent.

Jon: It's not about the applicability but about the operation.

John: Better to describe the intent, than describing what we do want to be used.

Daryl: Hakim, can you put together a couple of proposal for the next call?

Hakim: Yes.

- -- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6AnE4ACgkQ9RoMZyVa61eqRwCeKRXzOPuGyFM7Bar8EuZqra8Y
R7UAn3TyrAbPJY7k/DK5aqDrs7YzTciq
=fxUH
-----END PGP SIGNATURE-----