Chairs:
Eric Burger <eburger@standardstrack.com>
Spencer Dawkins <spencer@wonderhamster.org>
Scribe:
Spencer Dawkins <spencer@wonderhamster.org>
Jabber Scribe:
Dale Worley <dworley@avaya.com>
The chairs had pre-bashed the agenda, dropping considerable MRB discussion time in favor of an MRB editing session during the remainder of our meeting timeslot.
Robert Sparks said that he would set aside space for MEDIACTRL testing at SIPits, if we want to do interoperability testing there.
Robert also graciously reminded the working group that he would be irritated if he receives a publication request for a draft version with SIP nits in itJ…
We noted that SIPREC may be interested in using MEDIACTRL – the chairs will discuss with Gonzalo about whether any new work resulting would be handled by rechartering MEDIACTRL or by DISPATCHing it as new work.
We worked our way through questions that have arisen during mailing list discussions, and during RAI expert review…
Is it OK to drop INFO? None of the media servers that anyone in the room knows about emit OR process DTMF using INFO (except optionally in gateways) – it’s OK to drop this.
Schema extensibility? Dale Worley suggested that we pay attention to schema extensibility – the answer may differ by element. Status wouldn’t be a likely candidate for extensibility, because other devices have to understand status, for example. We think we have extensibility where we need it.
Call leg management – do MRBs allocate their own URIs? Jonathan Lennox said that we can’t stop an MRB from doing that. Dale suggested that we include an example in either MRB or call flows; Eric likes call flows better.
Multiple control framework sessions to different media servers? A new token at the SIP layer is the wrong answer. Eric said “tough”. Adam asked if this is always 1:1, and whether that matters at all. Is any change required? Dale said that it would be acceptable for an MRB to allocate a series of URIs that each point to different media servers.
The following topics are from RAI expert review (thanks, Ben Campbell for being our expert reviewer!):
Why not SIP events? We’ll keep things as they are.
IAMM with 3XX is like query – why are there two ways of doing the same thing? We think this should “just work” – it’s straight 3261. Dale suggested that we include this in an example in the call flows document. Spencer asked that we not require protocol changes (we don’t think that we do).
Eric should say something about SIP events in the shepherd write-up.
Consumer request with no SDP must have response?
Dale said that if a SIP element sends an INVITE, a 3XX isn’t a response that does what the SIP element asked for – so there’s no response payload in the 3XX response.
Eric said that we can’t change SIP behavior here – does anyone actually need this? Lorenzo thought it sounded reasonable but couldn’t remember details.
Gary Munson said (on the mailing list) that he was ok with removing 3XX.
Eric asked if it was OK with Robert if we were totally silent on 3XX, and Robert said it was OK.
Inline MRB acting as a B2BUA? This is similar to caller-prefs – we’ll look at RFC 3841. This was the original vision – is it right? Robert said, not a simple answer – we should treat it as a hot issue and work with Ben Campbell on-list.
Multipart/Mixed? We will change the text on required/supported and on ordering – this is clearly wrong. RAI Expert Review comments will be added to next version.
Lease mechanism? MRB managing resources or just keeping track of them? Can MS and MRB get out of sync? Can a MS be contacted directly (which might cause MRB to get out of sync)? What if multiple MRBs are involved? What is the scope of "expires"? Gary Munson has already sent comments on this, and we need to clarify the text in the document.
“Multiple MRBs”? These are excluded by definition in the document – the MRB is a logical entity (which could be made up of multiple physical entities, but they still constitute one logical entity). Robert asked if anyone cared besides Ben and Lorenzo – no one in the room cared.
Error codes? “Yes”. The next version of the draft will contain all error codes.
Scope of uniqueness? The current proposal is fine.
Sequence number gaps/rollover/ directionality? The authors will clarify this in the next version.
Non-active sessions reported? Will clarify what “non-active” means for mixers and RTP-sessions.
MS status field “deactivated” versus “unavailable”? We don’t think it’s harmful to have both, but there’s no guidance in the text about when to use one status or the other. We think “unavailable” means “not likely to be back soon, but will be back eventually” – Adam suggested that we use “unavailable” for the “draining” case (“not accepting new requests”), and we asked Adam to send text.
Contents of “name”, “package”, etc.? We’ll clarify this. James Polk asked that we point to a registry for codecs.
Security considerations? We need to point out in the document that an MRB in IUMM configurations modifies SIP bodies.
Channel security versus authentication? Gary Munson wants authentication to be optional. Dale agreed that the MRB can use any mechanism, but asked what the AS would do. We’ll suggest SIP digest authentication. Lorenzo pointed out that query mode uses HTTP – we’ll suggest digest mode authentication there, as well. Eric asked if we needed to say something about upgrading. Robert said “if you’re talking about something in SIP or HTTP, just do the right thing” (we don’t need to invent anything for MRB). Eric asked if we should mandate use – we got two “no”s in the room. Robert said he would check for dragons (and one dragon is “why not use mutual TLS?”). We discussed using the same credentials for both protocols, and said “no” to that, too.
Version 03 of the Call Flows document is aligned with version 03 of MRB.
Dale Worley asked if an IUMM MRB could also be a SIP proxy? Yes, there’s no requirement that this be a B2BUA.
There is still some text fine-tuning to do, and the authors will align with any changes to MRB or other MEDIACTRL specifications.
We expect to WGLC the next version of this draft.
We did not adjust any dates for MEDIACTRL deliverables.
We do not plan to meet at IETF 78.
We adjourned early to make way for an MRB editing session, to provide proposed resolutions for the MRB Expert Review comments.
Spencer will be stepping down as co-chair after IETF 77, in order to focus on his new Internet Architecture Board responsibilities. He wishes the working group well as they finish up!