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

Thank you for the notes, Christer!

Session participants, please review and send any corrections to the list.

Jean

On 4/5/17 2:05 PM, Christer Holmberg wrote:
> 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.
> 
> 
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 