BLISS MINUTES IETF71

Notes by Spencer

SIP Services Draft: brief overview combined with a question about how many people had read it (5-10). Also asked who found it useful, and what we should do with it.

John Elwell: Useful, but not clear how much new information, therefore not completely clear what to do with it.

Mary Barnes: strong overlap with SIPPING guide, and therefore not really a need to do this here. May be out of scope.

Jonathan Rosenberg. This is a useful collection of information as input into Bliss design teams. May not survive in the long term, but a useful working tool for the BLISS design teams.

Christof? Good input and something that is required by the design teams.

Notes by James

Thomas Fromont presenting – the goal here is to narrow down the number of names, since there are 5 names for just about every service (not to standardize complete services).

Ideally, this draft would be input to design teams (now) and go into a “BLISS hitchhiker’s guide” later, but it’s kind of late to be input to design teams. Mary Barnes also pointed out that this overlaps documents produced by SIP WG.

Jonathan Rosenberg does think that the document should continue as individual for now (not a standalone deliverable).

Christer likes the document and thinks this helps with the first-meeting goal to look at what other SDOs are doing.

Notes by Spencer

Document identifies potential measures that may be required
1. Conflict between what the proxy tries to do, and what the UA tries to do.
2. Conflict between UA’s (that may all be registered against the same AoR)
3. Obtaining information from UA for ACH at proxy needs to be reported in a consistent, and unambiguous manner. May need standardized response codes and semantics.
Jonathan: surprised at use of DND conditions…
4. informing the calling UA on what has happened. Seems to be little impact on interop, but is rather an issue of how much info can be conveyed. Therefore not a priority now.
5. Scope of conditions. Some conditions may not apply to all branches, or may not apply in the same way. Are there certain responses (6xx) that we may want to avoid in this context.
Francois Audet: Question to group. Do we think that 6xx is a mechanism to kill all forks.
Martin Dolly: In the field, one problem is that many response codes 4, 5, & 6xx are often ambiguous. Therefore he would much rather create new and explicit response codes, rather than add further overloading of existing codes.
Jonathan Rosenberg. Agree that we need to be explicit, but do not change the meaning of 6xx. Consider means to be very explicit in what we want to have happened.
John Elwell: Need to differentiate between saying what we want to have happen, and providing info on what has happened. We need to think clearly about these two. E.g. an explicit forward to voice mail indication is not a response code, but rather it is equivalent to doing the forwarding to voice mail in the UA.
????: 6xx in many cases is destructive of interoperability.
Francois: Warning (should be in spec). There are environments where they simply will not interpret a 6xx as meaning “kill all forks”. Examples are 911 contact centers and other call centers. Doesn’t change the recommendation, just something that this group will need to be aware of.
6. Configuring the proxy. How does the UA discover and change proxy settings – especially an intelligent UA discovering, rather than the end user discovering.
Jonathan. This is one of the most important looming problems, and therefore this is an area that we really need to say something about.
JR: Litmus test. Ask ourselves if different configurations would result in different implementations not being interoperable. If this still happens in a significant number of cases, then let’s not be afraid to add more detail to address the problem.
JE: if we have a web configuration interface, is that enough to address this.
JR: For simple phones, you can only count on “buttons” so we need to worry about this.
JE: This is the difference between ACH at the phone vs. in the proxy.
JR: We have choices here. Could say everyone must implement at UA, and therefore not an issue. Or minimum features at server, and must do this to guarantee interop. Just say something, and let people comment or object.
JE: Could have the same UA designed to work in various environments – enterprise where it will have to be proxy, as well as res where it will be in the UA. This further complicates things. Also could have a res UA based ACH which will revert to proxy when calls 911.
Martin Dolly: Need a mechanism for the UA to give control to the proxy. Need more use cases to explore this. Solution set needs to address the co-existence of both solutions. At a minimum look at UA deferring to the proxy, and then see what is still broken.

John Elwell: Late start, but we need to now kick start this with “inspired input”. Francois Audet has been brought into the team.

Actions for the design team:
- clarify the use of 6xx
- what can design team do in terms of provisioning.

Francois: Until we have a reason to move to a design team sub list, we should leave on BLISS. Otherwise we get too little input.
JR: that is the purpose of design team – produce draft for consideration
JE: problem is too little input on design team list
MD: moving meetings to later in the week would also be very helpful (as suggested many times…)

Who has read – dozen-ish
Is it ready for to move forward? Conclusion: need further analysis before moving forward.

Notes by James

John Elwell presenting – this is an update of the working group draft. The biggest addition is text describing the survey results presented in Vancouver, and some potential measures, such as

· How to control whether a proxy defers to a UA or vice versa

· How to resolve conflict between UAs (probably nothing BLISS can do here)

· How to obtain information from UA for ACH at proxy (there is no consensus on correct response code for DND)

· How to inform calling UA about what has happened (seems to have little impact on interoperability, propose not to pursue in BLISS)

· Scope of conditions (6XX means “all contacts”, but we usually wish that it meant “all contacts except for the voice mail endpoint”. Should we even be using 6XX at all?)

· How to configure the proxy (generally outside the scope of BLISS, but this does include UAs discovering how the proxy has been configured)

Jonathan was surprised that DND was showing up on the UA at call time (thought the point was that you didn’t disturb the UA at all).

Jonathan thinks that configuring the proxy is the biggest problem area – not saying anything here is bad. There’s a litmus test – if we don’t write something down, do things still work? If not, we’re not finished, SIP still isn’t interoperable, and we still have work to do. Yes, there are web interfaces, but hard phones do this with buttons, and even some soft phones use something besides web interfaces to manage proxy configuration from the UA.

The design team has a lack of inspired input (mostly due to Christmas).

Francois Audet asked the group for a sense of whether 6XX really does mean “kill all the branches”. Martin Dolly doesn’t think interpretation of response codes isn’t always clear (this is a problem in the field) – creating a new response code is better than overloading.

Jonathan thinks that twiddling with 6XX is a bad idea because so many devices are hardwired to kill all the branches now – if you want to go to voice mail, redirect to it, don’t change what 6XX means. Of course, this assumes that you’re doing DND-to-voice mail in the UA…

Scott thinks 6XX is an assertion of global knowledge and does kill all the branches – hard to prune carefully when you have forking, etc.

Francois pointed out that some environments just won’t process 6XX (emergency calling, etc) – need to write this down.

We recognize that there are different environments (proxies may want to control everything in an enterprise environment), and we need to accommodate this variety, but we still have to ensure interoperability to the greatest degree possible.

Martin Dolly says he needs a mechanism for a UA to control a proxy, because he has field problems without such a mechanism.

Shida asked Jonathan to send guidance to the design team about the configuration issue.

Francois said the group is overusing design team mailing lists – that’s one of the reasons why there’s so little input. Jonathan disagreed, but there are no comments on the design team list on this issue.

Martin asked for a design team time change (this would also improve the level of participation).

Is the analysis complete? Goal is to publish the analysis as informational and make recommendations as a BCP – John thinks it’s too early to start on recommendations now.

Notes by Spencer

Open issues:
1. how to transfer call completion support indication. Use Call-info header in response.

2. How to correlate the original INVITE, SUBSCRIBE request with the recall INVITE. A couple of possible approaches here, with pros and cons.
JR: Does not like using the call id – is a violation of 3261. Prefer use of URIs to do this instead.
DA: Issue is that the recall could go through a different gateway and URI is lost
JR: How would call id help, without state…?
DA: ?
JR: Why would this go to different media gateway if on net.
DA: Load balancing
JR: Is this just a PSTN interop problem
DA: More or less is just a PSTN interop problem
JE: Quite like the solution that Jonathan proposed. The one proposed here will not work when B2BUA translates the call ID.
DA: Design team was not explicitly looking at B2BUA scenario. Did not want to invent new headers, which limits.
JE:
Keith Drage: PSTN interworking – need to keep TCAP and ISUP interworking separate. Also may be worth re-examining the requirements. Should revisit the original needs for the re-invite, since it may have gone away because the originally intended need may have gone away.
Dale Worly?: With a constellation of gateways for load balancing, the solution needs to be designed for the case where no information flows end to end between the UAs. Could end up in a tug of war between B2BUAs in the network and gateways.
Adam Roach: Responding to Keith’s suggestions. Thinks the info may be needed for SIP to SIP case. Second, the id does not have to be random. It could be some hash of the state information without exchanging the actual info
DA: With this draft we are moving in the direction of a very specific hash.
AR: Doesn’t necessarily require standardization. Also needs to be invisible to the user.
DA: Draft is now giving examples of this, and also makes it clear doesn't need standardization.
AR: Put in the user portion.
Janet Gunn: Do we need to differenttinate between user busy and GW busy – wanting to queue when GW busy.
DA: This is exactly the sort of thing the draft is intended to deal with
Keith Drage: If we do this, then it is no longer a call completion service. Useful, but a different thing.

3. Caller should be able to suspend and resume the active subscription. (e.g. when on another call, want to suspend active subscription.)
JR: What is the semantic of suspension:
DA: Two parties queued, but the top one makes another call, allowing the second in the queue to bump up.
JR: Going to suggest something different. Monitoring to state, but state does not have single sources. So why doesn’t the client publish the fact they are busy. Have the presence model in mind. There are many inputs, and the net presence depends on the combination of all these states.
AR: Presence publishes to my AoR but here I’m publishing to your AoR.

Chair: running out of time, so let’s take it to the list.

Notes by James

Denis Alexeitsev presented – this draft is once again a major revision, moving to IETF language and adding call flows.

Open issues:

· Transferring the call completion support indication (Call-Info header)

· Correlating the original INVITE, SUBSCRIBE request and recall INVITE (several solutions proposed here, including using the same Call-ID value, but solutions have issues in PSTN interworking, etc)

· Suspending and resuming an active subscription (lots of solutions here)

Jonathan points out that reusing the Call-ID is an RFC 3261 violation, and didn’t think that calls would go to different gateways for the same destination endpoint.

John Elwell raised the issue of B2BUAs here.

Keith Drage pointed out that there are ISDN-ISUP issues that affect correlation as well – from memory, there is no relationship between the fields in ISDN and ISUP messages. Adam Roach thinks that this correlation actually is possible.

Dale Worley said that the entire mechanism has to work when no information flows from called party to calling party – this is the extreme case. Call-Info header is useful but can’t guarantee that this header will travel end-to-end. There are environments where you can’t subscribe to a phone unless you’ve called it (so that you can’t monitor someone else’s phone without them knowing).

Adam thinks that the proposed hash can pass state back and forth based on local policy without having to share state among multiple network elements. This can be invisible to the caller and still work.

Janet Gunn asked about extending the use case from endpoint failures to midpoint failures (“couldn’t get a trunk”). This is actually why the design team wanted to split out the monitoring function – to accommodate these types of use cases.

Jonathan asked what the semantics of suspension are – what does the monitor do differently? State doesn’t have to have one source – could the client just listen?

Adam pointed out that when I’m publishing state, I’m publishing to MY AOR, not to someone else’s AOR – REFER is good for this

Notes by Spencer

There are major changes from the -00 version, and there will be more based on discussions today.

Dialog package extensions:
- <appearance> element
- <exclusive> element – a hint that this should not be shared. Enforcement is a separate issue.
- <joined-dialog> element - covers case where calls are being bridged, by providing an ID for the calls that are being joined together.

Issues:
1. Appearance Selection: There are race conditions, and some proposals violate RFC 3265. To resolve this now suggesting using a publish only mechanism.
Discussion of whether or not this is the semantics of Publish. Rohan Mahy suggested this is really the semantics of grabbing floor control.
Alan Johnson: Think that extensions would be required to floor control protocol, and only use 10% of floor control
RM: Disagree with both. Are we trying to gain control of a shared resource? If so, then this is by definition floor control.
AR: What is the shared resource we are trying to get control of? A number? This isn’t a real resource.
RM: The resource is “line 2” which has an LED associated with it. But this is a silly requirement since SIP phones have infinite resources, and there is no need to generate an error when two people simultaneously hit “line 2”.
⇨ strong opinions on both sides, but no consensus in the room.

RM: It is not “every phone” that needs this. It is only phones that want to do seizure. Rohan does not believe this will be many, and that one floor control can be used for many many phones, even if you do want this.

AR: Does anyone else have an opinion on this? (=> silence…)

Hum:
Do people feel the use of publish for appearance selection is unreasonable?
Do people feel the use of publish for appearance selection is reasonable?
(Sounded like a tie to me…)

2. Appearance Element Attribute Issue: Nice optimization, but don’t really fit, so we will likely be removing them.

3. Dialog Package ID Issue: Could have collisions in the event state compositor.
RM: This is not a collision. Does not need separate documents for each UA. All the compositor needs to do is assign a unique identifier to each UA and append it to the ID it receives. This way what is published is unique.
DA: Not intuitive, so we will need to add text to make it clear.

4. Multiple Approaches Issue: Multiple approaches to multiple appearances. Current approach in the document is that Servers can use either approach, and UAs can solve either.
Dale Worly: there is a trap here as written. Some further clarification is needed.
Adam Roach: hesitant to require the server guys to do twice as much work, especially since in practice the server vendors will just pick one and do it.
DA: Reason for centralized is that if you have 100 UAs do you want all 100 to register. So if you only occasionally answer, then just subscribe to state rather than register.
AR: This seems dangerous…
Brian Rosen: The whole point of this group is to document one approach. Pick one and publish.
DA: Which one?
BR: Don’t care – pick one and publish.
DA: Simply not sure how to force one mechanism over the other, since they are happening in different elements.
RM: this seems like a sketchy road to go down. Not buying into the scenario. If you want to ring your device, and it is going to ring in the same way as if you were receiving an invite and sending a 180, then you should receive an invite and send a 180. Otherwise you will be missing out on lots of critical detail.
DA: But that would be a recommendation, not a requirement.

Back to the design team.

Hum:
Do people feel this is a good starting point for design team
Opposed?
Ans: I think those in favor won – slightly

Notes by James

Alan Johnston presented – major revision since 00, no longer just a requirements draft. Major changes to appearance selection, new sections on dialog package extensions, etc.

Appearance selection issue is mostly around a race condition. The current mechanism (SUBSCRIBE/NOTIFY in both directions) seems to violate RFC 3265, and it’s ugly. Suggesting use of PUBLISH-only (this is in the draft, but it’s been optional, and some implementations have used SUBSCRIBE/NOTIFY instead). Just need a 4XX response code to signal the race condition failure (could reuse 409 or use something else).

Dale Worley said we’ve been misusing SUBSCRIBE/NOTIFY as an RPC, and now we’re going to use PUBLISH as an RPC, but Alan thinks the semantics are closer (since PUBLISH has already changed the state).

Adam said that having a 409 that says “this won’t work given the other state I have”, and thinks this is exactly the PUBLISH model. Rohan disagrees – this is all about seizing exclusive access to a resource. This is floor control. You’re doing an action and hiding it as a state change. You wouldn’t have to change BFCP in order to use it here. Adam challenged the idea that a number is a resource here – it’s ephemeral. But Rohan pointed out that ephemeral numbers map to real LEDs on real phones, and challenged the manhood of this feature in a falsetto voice. He also said that even phones with multiple line appearances don’t have to use exclusive seizure – one floor control server could support thousands of phones, and may need to be in many networks for conferencing, anyway.

Do people WANT to use floor control for this? John thinks we need a simple solution, and BFCP wouldn’t be a simple solution.

Keith says we’ve already been here with previous call completion discussions – once you’ve handled all the edge cases, you’ve done an equivalent amount of work to adding the right protocol.

HUM: Use of PUBLISH for appearance selection is reasonable, or unreasonable? Hum in the room was 50-50 split called by the chairs.

Editors will remove appearance element attributes (not compatible with PUBLISH).

Dialog Package ID issue – we can get collisions between UAs. Rohan challenged whether these are collisions or not – they are, at the compositor. We have the same issue with other XML documents. Adam says we have to fix this or change the approach in the draft. Alan thinks the proposed approach is not intuitive and definitely needs to be defined in the draft.

Do we want to support two ways to implement MLA service, mandatory for all servers? Both operations are legal SIP operations. Adam doesn’t like saying “you have to do twice as much work to implement a feature”, especially because vendors may pick one, anyway. Brian Rosen said “please pick one way, don’t care which way”. John Elwell says he’s OK with having both ways because implementers have to implement this functionality anyway, for other uses.

HUM: Is this document a reasonable starting point? Lots of hums for “yes”, none for “no”.

MINUTES from BLISS WG session at IETF 71

Original Notes