New draft submission

1.1 =20 BLISS

1.1.1 = ;=20 Agenda Bashing / Status = Update

Presented by: Chairs

Jason=20 unable to attend today=85

Design=20 teams have been very active, but mostly NOT on the list.

Call=20 Park/Pickup =96 no teleconferences so no progress.

1.1.2 = ;=20 Automaric Call = Handling

Presented by: John Elwell

Draft:draft-ietf-bliss-ach-analysis-02.txt

Two=20 topics at last meeting that we decided not to address at last meeting. = Focused=20 on addressing conflict between proxy and UA (don=92t want them to = interfere with=20 each other if they can both do ACH) =96 mostly focused on making sure UA = doesn=92t=20 interfere with proxies.

Proposing that dataset draft (in SIPPING, but it=92s not a = working group=20 draft) is extended to include a parameter.

Jonathan=20 was very concerned that this is a huge hurdle =96 configuration = framework isn=92t=20 widely deployed today =96 just to support one configuration issue. = Don=92t think=20 people will do this.

Francois=20 =96 if this is a config option, just say that. If config framework ever = takes off,=20 we can add the parameter then.

Mary =96=20 why invent another way when we=92ve got the config framework?

Jonathan=20 =96 benchmark is phone and PBX from different figures just work =96 if = you don=92t=20 include a way to configure, is that helping interoperability?

Martin =96=20 these devices already have a configuration capability, and most have = ability to=20 turn capabilities off and give control to the proxy. Already exists and = is being=20 used.

Shida =96=20 so we don=92t need to standardize anything here?

Jonathan=20 =96 configure this property through whatever method your device=20 supports.

Lots of=20 discussions on design team about getting information from UA for ACH at = proxy.=20 Down to busy/explicit rejection/silent rejection and local/global=20 scope.

487 code=20 use is different from what=92s in 3261. No recommendation for global = silent=20 rejection code value.

480 is=20 suggested for DND in 3261, but this looks like overload with edge proxy=20 indicating temporary lack of resources.

Is=20 global silent rejection a RUCUS topic?

Francois=20 - Is there a reason you want to reject globally silently? If this is nothing but SPIT, = leave it=20 for RUCUS or some follow-on.

Is=20 anyone concerned about overloading 480?

Francois=20 =96 don=92t have a concern about this, but if someone does, it=92s a = 3261 issue and=20 don=92t think it=92s caused interop problems. Don=92t worry about this = unless we see a=20 reason to worry.

Don=92t=20 alter meaning of 6xx response codes =96 if something global is required, = use=20 4xx/5xx.

Configuring ACH at the proxy from UA =96 XCAP considered to be = overkill,=20 Jonathan proposed REST =96 how to extend this, and where to standardize=20 it?

Not a=20 lot of list discussion on this topic. Any issue in pursuing = REST?

Francois=20 =96 REST is a trivial solution =96 good, but don=92t think it=92s only = used by ACH =96=20 would be used by a number of drafts.

Would=20 need to set up a registry.

Is this=20 limited in scope to BLISS?

Jonathan=20 =96 suggested this instead of XCAP because REST is deployed all over the = network =96=20 Web 2.0, just use the framework, who needs a registry?

Scott =96=20 support this in general, but don=92t generalize into a framework until = we=92re sure=20 we have something that works. There are lots of PBX features people want = to=20 support from phone-tops. Think we should focus on example first and get = it=20 working =96 then generalize.

Mary =96=20 go ahead and take a higher view, use this as a use case.

Jonathan=20 =96 =93agile process=94 =96 have next rev of document, look at it and = decide. Don=92t=20 think I know what a framework for this looks like. XCAP disappears in a = puff of=20 smoke when you say =93REST=94. One step at a time.

Allen =96=20 seems reasonable for trivial things =96 won=92t you get into situations = where you=20 need to read?

That=92s=20 actually GET=85 This is running on the Internet for way more complicated = stuff=20 than this.

Keith =96=20 haven=92t decided what parameter to set yet, so need to understand scope = first.

Jonathan=20 =96 the world has moved on here. We need to wake up and smell the = coffee. Concept=20 is similar and doesn=92t have XCAP=92s problems.

Keith =96=20 don=92t agree with the way forward =96 should be a different document = that makes a=20 case for a different configuration framework.

Don=92t=20 want to specify exactly what ACH is =96 very service-provider-specific, = not what=20 we are trying to do in the IETF.

Christer=20 =96 may not have common understanding of what ACH is.

Martin =96=20 we know how to turn these parameters off and on =96 look at that, start=20 simple.

Jonathan=20 =96 just agree on parameters and interpretation by the process. If we can=92t figure out the = parameters for=20 minimal ACH, discussion of framework is pointless.

1.1.3 = ;=20 Call = Completion

Presented by: Denis Alexeitsev

Draft:draft-ietf-bliss-call-completion-02.txt

Suspend=20 and resume procedures proposed to use PUBLISH. Proposing CC event body. =

How to=20 correlate INVITE and SUBSCRIBE? Intermediate proxies might change = call-ID.=20

Adam =96=20 if you change the call-ID, you=92re not a proxy, and we shouldn=92t bend = over=20 backwards to accommodate SBCs.

Jonathan=20 =96 reality is that this is an unreliable header. Thought we had figured = out how=20 to do this without adding state (which is necessary from security=20 perspective).

Keith =96=20 what are you correlating? Initial INVITE and SUBSCRIBE.

Jonathan=20 =96 I thought we needed this because you can=92t ask to be queued for = call=20 completion if you haven=92t called the person yet.

Keith =96=20 that=92s in ISDN.

Jonathan=20 =96 security=85 if not, I can send arbitrary subscribes.

Keith =96=20 this is basically setting up a call for when a user is available =

Jonathan=20 =96 you either have to keep state or use a URI as a token =96 this is an = authorization question.

Keith =96=20 you don=92t need to create state.

(some=20 =93yes=94/=94no=94 exchange happened about here).

How to=20 route the suspension PUBLISH to the appropriate monitor? Send within the = SUBSCRIBE dialog? Use a GRUU received in the NOTIFY body?

Jonathan=20 =96 defer this feature =96 consumes resources in called party domain for = benefit of=20 calling party =96 already a disincentive for deployment. Not familiar = with PSTN=20 side, but if this can be rejected on PSTN side, should also reject it on = SIP=20 side. Don=92t think this is mandatory =96 people poll for this = today.

Francois=20 =96 getting complicated because we=92re trying to interwork with ISDN, I = think it=92s=20 implemented the same way as ISDN, we=92re getting complicated while = spinning our=20 wheels and making this less likely to be deployed.

Adam =96=20 not disagreeing with Jonathan/Francois =96 but if we do go down this = path, GRUU is=20 the way we=92re headed. I expect to press for deprecating anything = except GRUUs in=20 Contact header when we rev 3261.

Hums =96=20

=B7 =20 suspend/resume removed = from the=20 spec?

=B7 =20 unsubscribe and = subscribe? This was=20 silent.

=B7 =20 Event packages? This = was=20 silent

Trying=20 again

=B7 =20 Keep suspend/resume? = Sounded pretty=20 evenly divided (between keep/don=92t keep) =96 will take to the = list.

Adam =96=20 can we do basic feature and do extensions later? Nail down 99-percent = use case.=20 This is minor capability that gives us half the complexity in the=20 draft.

John =96=20 people can enhance later, this is taking a lot of time to produce, keep = it as=20 simple as we can, otherwise we=92ll never finish anything. If you want = the=20 callback feature, you probably want this finished quickly.

1.1.4 = ;=20 Line = Sharing

Presented by: Alan Johnston

Draft:draft-johnston-bliss-mla-req-02.txt

Three=20 methods (INVITE overlap is new). Need to pick one and go = forward.

Most UAs=20 don=92t have to implement any of the methods (don=92t have multiple line = appearances).

Adam =96=20 no matter what method we pick, something in the middle has to understand = MLA.=20 Implementation complexity is the same.

PUBLISH/NOTIFY has deployments, design team supports it. Floor = control is=20 cleaner architecturally but has no supporters. INVITE stretches overlap = dialing=20 but doesn=92t require protocol work.

Jonathan=20 =96 don=92t agree with 3265 violation. PUBLISH/NOTIFY is what people are = doing. Do=20 what people are doing if you want interoperability.

Francois=20 =96 list so far is nobody likes BFCP, support for PUBLISH/NOTIFY, was = thinking=20 INVITE was OK but don=92t like it now, looking at the call flows. Does = proxy=20 decide a line has to be seized, or is it the UA? Server would ask client = to say=20 =93tell me when you=92re in 100 state=94. Not clear what the intent was, = just=20 jumped into mechanisms. Regardless of choice, tempted to say that INVITE = is=20 least attractive of three choices.

Hum =96=20 strongly favored PUBLISH/NOTIFY mechanism.

1.1.5 = ;=20 History Info and = Diversion=20 Interworking

Presented by: Xavier Marjou

Draft:draft-mohali-diversion-history-info-00.txt

Two=20 solutions =96 Diversion header (proprietary but widely deployed) and = History-Info=20 (RFC 4244, also adopted by other SDOs but not widely implemented or=20 deployed).

Almost=20 no equipment supports History-Info.

Francois=20 =96 History-Info isn=92t Diversion, we=92re sabotaging History-Info by = dumbing it=20 down, so it won=92t work for anything except PSTN interworking). My = company is=20 guilty, too. Adding a parameter (as Jonathan suggests) is only way I see = to do=20 this that will work.

Mary =96=20 don=92t disagree =96 4458 isn=92t replacing History-Info. We started out = from=20 Diversion header, we have something general, if operators want this, let = them=20 pay vendors to develop =96 they aren=92t paying to develop = History-Info.

Ben =96=20 we=92ve decided not to go the Diversion route many times.

Martin =96=20 there are many SIP phones that support Diversion and won=92t be = upgraded. We=92re=20 going to be receiving this header for a long time. We need a way to = provide=20 interworking =96 that will help carriers decide to deploy = History-Info.

Steve =96=20 agree. Diversion is much wider than ISDN these days. Big bang scenarios = never=20 work =96 you have to have a transition story.

Jean-Francois =96 Diversion is there, widely deployed, in some = cases it=92s=20 what people need. Unanimous feedback from several operators in cable = space was=20 =93no, Diversion is there and it=92s good enough=94.

??? =96=20 Proposal is not to standardize Diversion header, it=92s to standardize a = mapping=20 mechanism. We have this problem today. We may discuss, but at least the=20 requirements are there.

Robert =96=20 apologize for the poke, but if you ask vendors to implement a = non-standard, the=20 pain should be yours. But let me ask =96 draft is proposing = bi-directional=20 mapping. Why do we need History-Info-to-Diversion mapping?

Mary =96=20 we implemented both, why can=92t you carry both and switch over to 4458 = for=20 interworking?

In some=20 cases, we do preserve both.

Francois=20 =96 not bidirectional, there are things you can=92t do in PSTN, so you = lose=20 information (forking in SIP, etc.). History-Info tells you what=92s in = SIP, not=20 what happens behind a gateway. If you merge them, you=92re changing = History-Info=92s=20 goal and it becomes unreliable at describing what happened to the = request. If=20 we=92re going to do this, why do we need History-Info in the first=20 place?

Jean-Francois =96 but you have a good representation of what = carriers are=20 saying in the draft. Problem is that operators need to deploy with = software=20 that=92s been tested in their labs and is available, at some point in = time. We=20 tried to get people to upgrade. It=92s not going to work. Some operators = are=20 deploying new SIP services and will require History-Info support, but = they will=20 have to deal with Diversion for a long time.

Christer=20 =96 this reminds me of INFO discussion=85 customers didn=92t ask for = Diversion because=20 it=92s better, they ask because that=92s what out there today. Maybe = mapping isn=92t=20 right term, but we need interworking. We lose information when we = interconnect=20 today.

Martin =96=20 we have a fair amount of wireline carriers globally and in the = US on this draft. If you = think every=20 vendor=92s product is compliant to these RFCs, you=92re nuts. There are = TAs, SIP=20 Phones, even IP-PBXes that do Diversion =96 if we don=92t go this way, = we=92ll just=20 fix the problems on an SBC.

Mary =96=20 we should do an informational spec =96 not standards-track.

Hadriel=20 =96 if we do this mapping, we get SOME information, but if we don=92t, = we get NO=20 information.

Jonathan=20 =96 agree with many folks, including Martin(!). We can=92t just change = SIP when we=20 have a new idea. Agnostic on details here, but discussion about this = topic is=20 the right thing to do =96 not doing it is like ignoring NATs. Not just a = service-provider problem, it=92s also deployed in enterprise = networks.

Jean-Francois =96 rough consensus and running = code=85

Francois=20 =96 this is surreal. We=92re lobotomizing History-Info to do this = mapping thing.=20 There is a problem. Best way is to do this in parallel (with a real = History-Info=20 definition). If group doesn=92t think that=92s a good idea, we have to = do transition=20 in non-destructive way to show this is a redirection in the classical=20 sense.

Keith =96=20 draft is about interop =96 if it=92s supposed to be migration, you need = to say so in=20 the draft.

Robert =96=20 no one has answered my question =96 asking again. Can see mapping in one = direction. Is there a need for a bi-directional mapping?

Martin =96=20 IP-PBX call center, may have multiple redirections=85

Robert =96=20 that=92s scale =3D 1, not scale 100,000 and nothing is making = History-Info now =96=20 what=92s the chances it will start showing up?

Hadriel=20 =96 seeing History-Info in peering situations (but they may be mapping = it right=20 back to Diversion).

Eric =96=20 draft is expired and five years old.

Spencer=20 =96 this is the kind of thing Informational publication is=20 for=85