SIPCORE IETF 84

Contents

Agenda and Status

Charter Item: WebSocket Transport for SIP

Charter items: Mechanism to indicate proxy capabilities

Issue 1: Feature Capability Indicator name

Issue 2: IANA SIP header field parameter table

New work proposal: Reverse Keep-Alives

Open Discussion

Date: Friday, August 3rd, 0900-1130
Location: Vancouver, BC, Canada
Chairs: Adam Roach, Paul Kyzivat
Minutes: Jean Mahoney
Jabber Scribe: Jonathan Lennox

Agenda and Status

Presenter: Chairs
Slides: http://www.ietf.org/proceedings/84/slides/slides-84-sipcore-1

Best presentation of a Note Well ever. Note Well was applauded. And read. (See http://youtu.be/w8q3fD1KDzY).

Adam presented WG status slides.

rfc4244bis-callflows - Minor comments received yesterday, author has indicated that update will happen soon.

rfc4244bis - Shepherd write-up done, will be Publication Requested soon.

Charter Item: WebSocket Transport for SIP

Presenter: Victor Pascual
Slides: http://www.ietf.org/proceedings/84/slides/slides-84-sipcore-0
Draft: draft-ietf-sipcore-sip-websocket-01

Victor presented slides.

Victor received some comments from Cullen yesterday. He will take them to the list since Cullen is not here.

Victor believes the draft is stable. There are implementations, and feedback from the implementors is great. Ready for WGLC?

Partha: there's was discussion around the fact that this transport will be implemented predominantly in web browsers, which cannot use TCP and UDP transports for SIP. But RFC 3261 mandates TCP support for SIP. This document needs to discuss such compliance issues.

Victor: In the browser environment, the UA can't implement UDP or TCP. If we want to do this, it should be in a separate doc. It's not the main goal of this doc.

Partha: We're introducing a new transport, please document.

ACTION: Adam to Partha: suggest text to the list.

Partha: Should have more clarity around authentication. We have 2 app layers, which should be used.

Victor: We have a section on that.

Partha: Double authentication is okay?

ACTION: Victor to Partha: Please propose text on how to clarify.

Adam (as an individual): This draft has solidified well.

Adam (as chair): Hands of who will do review? 4 hands raised

ACTION for chairs: Adam: Good - will move to WGLC next week.

Charter items: Mechanism to indicate proxy capabilities

Presenter: Christer Holmberg
Slides: http://www.ietf.org/proceedings/84/slides/slides-84-sipcore-2
Draft: draft-ietf-sipcore-proxy-feature-04

Christer presented slides

This document has gone through WGLC. Christer presented 2 issues that had no concern on list.

Issue 1: Feature Capability Indicator name

Replacing "feature cap" with "feature capability indicator".

The group had no issues with this change.

Issue 2: IANA SIP header field parameter table

Since the feature capabilities indicators are header field parameters, should be captured in the IANA SIP header field parameter table.

Christer showed a slide of how the table would look.

Andrew: How do you put in registry?

Christer: We follow IANA procedure

Andrew: This is just a parameter.

Christer: The tokens remain the same.

Keith: You need to say that valid feature caps are subject to the feature cap registry. We're updating the bar because it applies for the header field param. Need to say you are downgrading (lowering, ed.) the bar. The bar is this table rather than headier field table.

ACTION: Paul to Keith: Please propose text to the list.

Adam: RFC 3968 is what he's referring to here.

Paul: I don't see anything that requires another WGLC. We'll submit after edits are made.

Keith: my proposed changes do not introduce technical changes.

New work proposal: Reverse Keep-Alives

Presenter: Christer Holmberg
Slides: http://www.ietf.org/proceedings/84/slides/slides-84-sipcore-3
Draft: draft-holmberg-sipcore-rkeep-00

Christer presented slides.

Christer: Hadriel's name will be on the next version of the draft. There has already been a discussion on list for negotiation. RCS needs this. Want to give them a standardized version. Used for smart phone. Are we interested in the work?

Charles, referring to example callflow: Is the rkeep 25 response an independent message or a response to the rkeep 30?

Christer: It's what will be used. It's a response. I started with RFC 6223 and changed what needed to be changed.

Paul (from floor): Christer and I had a discussion on the list. Please look at the discussion. I just had objections to the message details, which are confusing.

Hadriel: We had this problem on some mobile phones. This solves it and is a simple thing. Is this something working group is interested in?

Christer: I've taken this to SIPCORE rather than dispatch because it's an extension of RFC 6223.

Partha: Isn't the edge proxy's SIP response a keepalive?

Christer: STUN keepalives are sent separately. Alice can't send STUN messages because of her OS, but can respond to them.

Hadriel: In the example, the message is a REGISTER with a REGISTER response. The proxy could send a OPTIONS request with a keep parameter, but this is cleaner.

Adam: Who has read the draft? (hands up)

Victor: I support this work

Adam: I need to talk to the AD since the work is not a direct match with the charter, but it's small, and we may not need to send to it dispatch.

Hadriel: Keepalives were done in this WG.

Adam: It was grandfathered.

Paul: When discussing putting Feature Caps in the IANA registry, I realized that we didn't do this for UA capabilities (RFC 3840). We probably ought to update that too. Need to look for a mechanism to do it.

Robert: There are some fuzzy edges to scope. I have no problem polling the room. My inclination that the work will be done here. More conversation on the list needs to happen since many couldn't make this meeting.

Adam: Should I call for interest?

Robert: I think you have it.

Adam: Show of hands: non-trivial.

Adam: anyone think it's a bad idea: No hands raised.

Open Discussion

Paul: Does anyone have a 4244bis implementation? - 1 hand raised.

Hadriel: The feature tags never got registered. Update those too?

Paul: need to find a procedure to do it.

Hadriel: has a plus...

Paul: we're registering the syntax. It's technically not required, but implementors want to see what's legal.

Hadriel: Implementors use wireshark and check in the registry.

Lennox: It's not sufficient to go to the IANA registry.

Keith: It's the references to the RFCs in the registry that you want.

Discussions closed and the Note Well was displayed again.