Agenda Bash – No changes.

 

Chairs Slides

 

Brandon Williams – third-party-authz Need to make sure that if we do this before STUNbis then need to make sure they are in sync may need to delay.

 

Turn server discovery – No pending comments.   Adam Roach, Andy Hutton volunteer for review draft-ietf-tram-turn-server-discovery-00.

 

Turnbis – Call for comments/reviews.

 

Stunbis – needs reviews.

 

Andy Hutton – The rtcweb-return draft may impact some of the turn drafts.

 

Justin - -return- impacts the auto-discovery mechanism so some requirements will trickle in to this.

 

 

ORIGIN draft.

 

 

J. Lennox– Raised issue of privacy concerns. Maybe only send Origin if auth is used?


Alan Johnston – Origin is useful for logging in general.

 

Brandon Williams – There are probably categories of TURN server that have no need to know the origin and therefore there are privacy considerations. The user might not want to send the Origin to some STUN servers for privacy reasons, especially when it is useless (e.g., public STUN servers).


(Brandon to start thread on the list about this subject before we start WGLC.) 

 

SSODA


Two open-source implementations: Pal's and Oleg's.


J.Lennox – Need to make sure existing TURN servers don’t catch fire.

Pal: We tested four implementations, no crashes found.

 

Justin – Recommends sending options (two options: a solution with an attribute and one without) to the list and having a discussion/decision so people can make an informed decision before deciding to incorporate in to TURNbis daft.

 

J.Lennox - The draft doesn't allow even/odd allocation at the same time as a dual-stack allocation. Why?

(Would require too many protocol changes.)

 

Hum – Strongly in favour of folding the draft in to the TURNbis draft.

 

 

TURN Mobility

 

Who has read the draft – 6 People.

 

Out of these who thinks it is interesting and will contribute – 4.

 

Who will implement – 1 (Pal)

(Oleg has already made an open-source implementation.)

 

Justin – Need to consider this in the context of the continuous nomination story. We need  a mobility story but not sure this is correct way yet.  How does this fit with ice-mobility. With ICE continuous nomination you can have mobility across candidates with signalling, therefore no need to keep the same TURN allocation across mobility events.

 

Bernard – does not fundamentally change ice-mobility.

 

Justin – This draft and continuous nomination run into one another.


Brandon: Mapping out the big picture of mobility is required to determine if TURN mobility fits in the big picture.

 

Bernard: Make before break implies you need two allocations.

 

(Will wait before the big picture is drawn before adopting.)


 

TURN Server Selection.

 

How many read this – 6.

 

Brendan – Is this intended to define you to prioritize because if it does it is going to be out of date very quickly.

 

Gonzalo S. – It is not intended to do that. The draft offers guidance, not prescription.

 

Justin – This should be informational as it does not provide enough guidance. BCP-type of document would be good.

(Justin promises to at least send an email.)

 

Hum – In favour of adopting this – Zero hums,  Against - Zero

 

Brandon – Interpretation of the lack of hums is that more discussion is needed.

 

 

TURN-Lite

 

Who has read this – 6.

 

Justin – Doesn’t understand the issue about a large number of relay addresses as this does not appear to be needed as only need one address and lots of ports.

 

Brendan – Agrees that addresses are not much of an issue.

 

Justin – How to the application provider know about the CGN’s.  Seems to a problem with the design in that the applications need to provision the CGN’s.  Believes that this makes the problem massively more complex.

 

** Google – Might want to consider using –return- in the ISP’s it might fit the use cases.

 

J. Rosenberg – The application is the most well placed to make the decision. If the CGN is BEHAVE-compliant, the hosts would be able to communicate directly using standard ICE. I don't see the path optimization that this provides.

 

Chairs – Good feedback please continue to discuss on the list.

 

 

STUN Transaction – Dan Wing

 

Dan – If interested in RTT change the transaction ID on each re-transmission.

 

Justin – Definitely interesting but might want to consider a new attribute for retransmission count.

 

Pal – Currently using transactionID’s for timeouts and heuristics to determine RTT and loss percentage.

 

J.Lennox - Only some kinds of requests can do this. Allocate Request: no.

 

Varun Singh - Could you use a timestamp.

Dan - Yes but there are issues because retransmissions need to be exactly identical.

 

Dan: One idea is to steal bits from the transaction ID and make a retransmission counter.


EOF