Big thanks to John Elwell and Adam Roach for taking the notes.
1. merged minutes
2. original notes by John Elwell
3. original notes by Adam Roach
- Agend bashing
- Call for help with editing "Call Park" feature draft
- Summary of draft changes
- Open Issue: Alert-Info, whether a URN is needed, similar to what is
proposed in draft-alexeitsev-bliss-alert-info-urns-01 to semantically indicate which
type of alerting to perform. This allows a proper syntax in the
"Alert-Info" header field.
- Draft is near completion, one more rev and could use an expert review.
- Chair asked for volunteers and following 4 volunteered.
- Status Summary (See slide)
- Have the final version by Stockholm, need some implementations (running code)
- A number of issues, but all easy to resolve and nothing contradictory. No questions.
Issue on whether to define XCAP profile, define XCAP-Lite to using REST like approach
Issue on feature creep/ Should there be a way to get all the attribute at once?
Issue on overlap with ACH:do we need to define which SIPstatus codes that trigger certain forwarding behaviors? Or is that part of the base ACH draft?
Chair asks for a feel of how the room feels about the draft.
John: Need first to determine level of complexity that people need, to
assess whether we approach the complexity of XCAP.
Markus: We already have a 3GPP standard, and we need to alreadyimplement that to interop with existing servers. However, if vendors are not going to implement that, then we need to define something here (IETF) that server vendors will implement. Otherwise, we'll have the 3GPP approach and
a lot of proprieatry mechanisms. From that point of view, the proposed approach is exactly correct.
Markus: Have you looked at the SIP configuration means definedby 3GPP for this?
Christer: Should avoid too many proprietary methods. 3GPP has a
lightweight version of XCAP.
Theo: I have personally looked at this, but we as design team haven't.
Chair: Are there other companies who have not implemented XCAP but would
implement this? Francois: What we have is something that's not XCAP, but something as complicated: SOAP. Agree that having something simpler makes a lot of sense. The approach we're discussing makes sense for things like setting call forwarding and activating services in a way that's compatible with other companies' phones.
Alan: We have proprietary method. We would probably implement this if it
is standardised. Like the direction.
Chair: Based on assumption scope will not get larger, people are
reasonably happy with the direction the draft is taking.
Cullen: It seems there is no objection from the WG.
Christer: Maybe I misunderstood, but does having something simple mean
something simpler than XCAP, or specifically this REST approach?
Shida: Is the general approach and scope the right direction?Can we take it as a milestone? Assume the scope does not get any larger.
Markus: A few of us had some issues with it -- when you say "general direction", do you mean that we want to do something simpler and more restricted than XCAP, or do you mean that we want to go forward with a REST-like approach?
Chair: Need to do another cycle of use case collection, to confirm that
we are heading in the right direction?
Francois: We have already given the author enough feedback to rev the
draft, so what more is needed?
Francois: Go through the draft and weed out the more XCAP-like cases.
Markus: We already have a good understanding of use cases, would be
happy to adopt now as work item.
draft-ietf-bliss-shared-appearances-02 (Alan Johnston)
Open issue on Alert-Info, whether a URN is needed, similar to what is
proposed in draft-alexeitsev-bliss-alert-info-urns-01.
In reply to question from Francois, Alan explained that the need for the
parameter was to achieve optimisation, in case where INVITE arrives
before NOTIFY. Also confirmed that the problem could be solved in other
ways, but Alert-Info seemed most promising.
Francois: If we do it this way, would have to revive the draft.
Francois: Or we could choose not to solve it in this document.
Alan: Yes, that would be a possibility.
Christer: Alexeitsev draft is already used by 3GPP.
Francois: If the URN has been registered elsewhere, we can simply use
it.
Cullen: The alexeitsev draft is not listed in 3GPP dependencies.
Sohel: Question on figure 2.
Alan: No
Sohel: If two calls come in, do they use different values.
Alan: Outside scope of draft
Obtained 4 volunteers for reviewing draft.
draft-ietf-bliss-call-completion-03 (Dale)
03 does not reflect a lot of the changes discussed recently.
Dale: Should have final version by Stockholm, but need implementations
to check it works.
Keith: Flows the same as the original individual draft, and as that
document was implemented and worked (based on ALU implementation), this
should work.
Dale: A number of issues, but all easy to resolve.
No questions.
draft-zourzouvillys-bliss-ach-http-api-01 (Theo)
Issue on whether having an XCAP-Lite
Someone ????: REST is better
Christer: Seems good reason to use XCAP.
Markus: 3GPP already has an XCAP-based solution, so a REST-based
solution will not help.
Derek: People with REST won't implement XCAP.
Questions from chair to assess who has implemented XCAP and who has
implemented REST. (???? didn't catch results)
Issue on feature creep:
Adam: Keep as simple as possible, because otherwise why not use XCAP?
Markus: No need to read all settings at once - can do as separate
requests. Keep as it is.
Roland: What we have at present from 3GPP is OK.
Issue on overlap with ACH:
John: Keep code mapping and 3xx handling in analysis draft.
Should we adopt this?
John: Need first to determine level of complexity that people need, to
assess whether we approach the complexity of XCAP.
Markus: We already have 3GPP standard and our company implements that,
but if other vendors find something else useful, this might still be
worth standardising, and what is in current draft is correct.
Christer: Should avoid too many proprietary methods. 3GPP has a
lightweight version of XCAP.
Theo: I have personally looked at this, but we as design team haven't.
Chair: Are there other companies who have not implemented XCAP but would
implement this?
Francois: We use proprietary. Agree something simpler would make sense.
So this would be good, but don't let it lead to another version of XCAP.
Use this for very simple stuff.
Alan: We have proprietary method. We would probably implement this if it
is standardised. Like the direction.
Chair: Based on assumption scope will not get larger, people are
reasonably happy with the direction the draft is taking.
Cullen: It seems there is no objection from the WG.
Christer: Maybe I misunderstood, but does having something simple mean
something simpler than XCAP, or specifically this REST approach?
Chair: Need to do another cycle of use case collection, to confirm that
we are heading in the right direction?
Francois: We have already given the author enough feedback to rev the
draft, so what more is needed?
Francois: Go through the draft and weed out the more XCAP-like cases.
Markus: We already have a good understanding of use cases, would be
happy to adopt now as work item.
Other business:
Sohel: Question about ringback tone. If SP A provides ringback tone to
SP B, is this a topic for BLISS?
Answer: Sounds like SPEERMINT.
Cullen: This is the early media topic, for which there are already
documents. If want to know how to use those documents in peering, that
is SPEERMINT, but if you want to revise those documents, perhaps SIP or
MMUSIC.
Intro (Chairs)
- Agenda Bash
- Call for help with editing "Call Park" feature draft
Shared Appearances (Alan Johnston)
- Summary of draft changes [see slides]
- Open issue: Alert-Info URN desired to semantically indicate which
type of alerting to perform. This allows a proper syntax in the
"Alert-Info" header field.
* Francois Audet: asks for description of the purpose of the
field, suggests using a Request URI parameter instead (so as
to avoid blocking on an additional draft. He points to the
possibility of another standards body that has already specified
the URN.
* Jason (as chair) suggests we should take the question to the list.
* Christer points out 3GPP is already using URNs in Alert-Info.
* Cullen: bliss-alert draft is not listed in 3GPP dependency list
* Anonymous from Nokia: It will be added to the next version
* Sohel Khan: Is there a way to have different references going
to multiple devices? [Answer: no, the point is to keep them
synchronized] Follow-up: does the first call need to be appearance
1? [Answer: no, they can be assigned in any order]
Call Completion (Dale Worley)
- Status summary [see slides]
- Keith Drage: points out Alcatel-Lucent already has a working
implementation of draft
- Open Issue: Call Completion requests are not correlated to the
original call. This allows attackers to make call completion
calls to the PSTN without having ordered the service. The plan
is to add text to the draft calling out this issue.
- Summary of status continues [see slides]
- No discussion or questions
ACH HTTP URI (Theo Z)
- Summary: Discussions have ranged from "using XCAP" to "use a REST
approach" to "create an XCAP lite profile".
* Derek MacDonald: Thinks REST approach is better than XCAP
* Christer: Disagrees
- Aki Neimi: 3GPP already has an XCAP mechanism for doing this.
- Derek MacDonald: Many vendors already have a RESTful API, and
could easily move to anothe RESTful approach. Adding XCAP
to these clients won't happen.
- Keith Drage: 3GPP has a standardized means of doing this already
using XCAP
- Derek MacDonald: Our client will probably end up implementing both,
but XCAP is very complicated, and many people won't do it. If
you standardize XCAP in here, we'll end up implementing a different
proprietary interface for each vendor out there.
- Theo Z: Should there be a way to get all the attributes at once?
(Crickets Chirping)
* Adam Roach: Keep it simple, or you'll end up re-inventing XCAP
* Aki Neimi: Generally agree, keep it as it is right now
* Christer: What is needed for the actual stuff we're
configuring?
* Roland Jesske: We have already implemented this in XCAP. What
we have with 3GPP works very well.
- Theo Z: Overlap with ACH -- do we need to define which SIP
status codes that trigger certain forwarding behaviors?
Or is that part of the base ACH draft?
* John Elwell: (Asks a clarifying question about the issue)
Perfers to keep the mapping in the analysis draft
- Shida (as chair): asks for a feel of how the room feels
about the draft.
* John Elwell: if we can keep this simple, then this seems
to do the job. If we make it too complex, it becomes
an "XCAP lite". So we need to ask people how complex
they think this needs to be.
* Name not announced: We need to ask people what the smallest
set of features required to make this useful
* Marcus: We already have a 3GPP standard, and we need to already
implement that to interop with existing servers. However,
if vendors are not going to implement that, then we need
to define something here (IETF) that server vendors will
implement. Otherwise, we'll have the 3GPP approach and
a lot of proprieatry mechanisms. From that point of view,
the proposed approach is exactly correct.
* Markus: Have you looked at the SIP configuration means defined
by 3GPP for this?
* Francois: What we have is something that's not XCAP, but
something as complicated: SOAP. Agree that having something
simpler makes a lot of sense. The approach we're discussing
makes sense for things like setting call forwarding and
activating services in a way that's compatible with other
companies' phones.
* Alan Johnston: We don't do XCAP; we have our own proprietary
mechanisms. If the IETF did this, we would change to it.
* Shida: Is the general approach and scope the right direction?
Can we take it as a milestone? Assume the scope does not
get any larger.
* Markus: A few of us had some issues with it -- when you say
"general direction", do you mean that we want to do something
simpler and more restricted than XCAP, or do you mean that
we want to go forward with a REST-like approach?
* Shida: We should take the use-case analysis back to the list.
Are people happy with the use cases?
* Francois: We gave quite a bit of feedback to go into the
document. What are we trying to figure out?
* Markus: happy with the general direction, would be happy to adopt.
Shida closes meeting.
- Sohel Khan: When carriers have something like ringback tone
requirements, does that go in BLISS or in SPEERMINT?
- Cullen Jennings: It depends on what you're trying to do. It
might end up in MMUSIC, SPEERMINT, or even SIP. But BLISS would
be a fine place to start talking about it.