[sipcore] IETF#98: SIPCORE notes (Christer)

[Christer Holmberg <[e-mail]>]

Hi,

Below are my notes from the SIPCORE session.

Regards,

Christer

---------------------------------------------------------------------------

Topic:                  SIP Call-Info Parameters for Labeling Calls
Presenter:          Henning Schulzrinne
Draft:                  draft-ietf-sipcore-callinfo-spam-00

What is it?


-          Defines SIP Call-Info parameters and a feature tag that allow originating, intermediate and terminating SIP entities to label calls as to their type, spam probability and references to additional information.

Presentation in a nutshell?


-          Generic presentation about robocalls.

-          Some are illegal, some are legal but unwanted, and some are wanted/helpful.

-          Call filtering can be done by carriers themselves, by carriers using third-party tools, or by a device itself.

-          Presentation of new SIP Call-Info header field parameters and an associated feature capability indicator.

What did people say?


-          It was asked whether it would be better to insert the information in the STIR PASSPortT structure instead. Indicated that it could be part of PASSPorT in the future.

Ok, so what next?


-          Additional comments are welcome.

-          ACTION POINT: Christer H and Paul K will review the feature capability indicator.

------------

Topic:                  Location Source Parameter for the SIP Geolocation Header Field
Presenter:          Roland Jesske
Draft:                  draft-winterbottom-sipcore-locparam-00

What is it?


-          Adds parameter to the Geolocation header field values to indicate the node that added the value.
Presentation in a nutshell?


-          Indicated that the feature is required by ETSI M/493 in order to assist downstream nodes.

-          Proposed to adopt the draft by the SIPCORE WG and initiate WGLC.

What did people say?


-          Some had issues with the use of domain name to indicate nodes.

-          The chairs asked people to review the draft.

Ok, so what next?


-          The discussion will continue on the mailing list.


Topic:                  Third-Party Authentication for Session Initiation Protocol (SIP)
Presenter:          Rifaat Shekh-Yusef
Draft:                  draft-yusef-sipcore-sip-authn-01

What is it?


-          Authentication mechanism for SIP, that is based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications.

Presentation in a nutshell?


-          Difference between the draft and a previous draft. The new draft is a scaled down version, where previously controversial parts have been removed.

What did people say?


-          Jon Peterson, who raised issues on the previous draft, indicated that he has some minor issues, but that he is ok with the scope of the draft and moving it forward.

Ok, so what next?


-          The chairs did a hum regarding taking on the work.

-          OUTCOME: There was a clear consensus for taking on the work.


Topic:                  ISUP Cause Location Parameter for the SIP Reason Header Field
Presenter:          Roland Jesske
Draft:                  draft-jesske-sipcore-reason-q850-loc-00


-          The draft had previously been discussed in DISPATCH (see notes for more information), where it was decided to move the draft to the SIPCORE WG and let SIPCORE decided on whether take on the work.

Ok, so what next?


-          The chairs did a hum regarding taking on the work.

-          OUTCOME: There was a clear consensus for taking on the work.


Topic:                  The Session Initiation Protocol (SIP) Digest Authentication Scheme
Presenter:          Rifaat Shekh-Yusef
Draft:                  draft-yusef-sipcore-digest-scheme-05

What is it?


-          Updates the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for SHA2 digest algorithms to replace the MD5 algorithm

Presentation in a nutshell?


-          Background what has happened for HTTP, and to apply the same for SIP.

-          Indicated that forking could potentially cause problems, if multiple servers are to be authenticated by the client.

What did people say?


-          It was questioned whether there is a need for a UA to authenticate multiple servers. It was indicated that it would be problematic with current behaviour of forking proxies. Nobody could identity a case where it would be needed.

-          Indicated that similar algorithm update is also done for STUN, so the author was advised to take a look at the STUNbis draft.

Ok, so what next?


-          No decision was made. Discussions will continue on the list.