Subject: [straw] Notes of Meeting

From: <[email-masked]>
Date: Wed, 1 Aug 2012 06:29:52 +0200

Dear all,
please find attached my notes.
If I have something misunderstood please indicate this on the list.

Roland

-------------------------------------------
Sip Traversal Required for Applications to Work (STRAW)
TUESDAY, July 31, 2012
1700-1830 Afternoon Session III
Regency E

- - Agenda bashing and IETF Note Well (5 min)
Presenter: Chairs

Christer: Introduction, Session should be seen as tutorial and starting point of work.

- - Introduction to the WG (10 min)
Presenter: Hadriel Kaplan
Related reading: STRAW WG charter http://tools.ietf.org/wg/straw/charters

Slides-84-straw-1
Hadriel:
Problem statement à B2BUA are not only SBC. So could be also other entities e.G. PBX ect.

It's impossible to specify everything that all types of B2BUAs must do for SIP  but very few things any B2BUA must do to make a specific mechanism work. Like loop detection (Max-Forwards)

Daryl: It helps but does not guarantee that it will work. The STRAW defined procedures will help for implementers.
Hadriel: Every RFC we will provide will work or.
Robert: This is a theoretical discussion.

- - Role-types of B2BUAs (20 min)
Presenter: Hadriel Kaplan
Related reading: A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents http://tools.ietf.org/html/draft-kaplan-dispatch-b2bua-taxonomy-00

Slides-84-straw-2

Slide: Proxy B2BUA

Keith: Does it have to sent BYE à Yes
Paul: Could keep contact?
Hadriel: Yes
Keith: Still proxy behaviour but will be a B2BUA due to replacement of elements.
Hadriel: Will replace headers or send also Messages.
Andrew: Will it be a functionality not a BOX?
Hadriel: Yes

Slide: Signaling B2BUA

Andrew Hutton: Sees also the modification of SDP as signalling
Hadriel: sees this as an other type of B2BUA

So this is not seen as manipulating SDP for media changes only to fix SDP.
Will be further discussed on the list.

Slide: Media Aware B2BUA

Keith: Should reference RTP RFC terminology the differentiate between media aware and media terminating B2BUA.

Will be taken into account. (List discussion)

Paul: What is the Criteria for B2BUA? One-to-one, call initiation into two direction or???
Hadriel: Some documents will define the taxonomity itself.
Paul: For Conference servers perhaps is not interesting for STRAW but e.g. for a PCC it is seen.
Keith: Will have documents in STRAW that is covered by the taxonomy document. Conference is out of scope for him.
Partaha: Thinks that it is needed more taxonomy functions.
Hadriel: Please put it on the list for discussion.
Martin: Conf is more an APP Server and there are Edge Servers and Application Server. Are these types covered?
Hadriel: Yes

Daryl: Proposes to mention within the draft the differences between types and add examples.
E.g. -This is a Media aware B2BUA and does...
     -If you deal with media than this is the procedure to do it.
     -If it is a Signaling then... And add some examples.

- - Loop detection/prevention (20 min)
Presenter: Hadriel Kaplan
Related reading: Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) http://tools.ietf.org/html/draft-kaplan-dispatch-b2bua-loop-detection-00

Slides-84-straw-3

Robert: Pointing the RFC5393 à will end up one Call, If you have forking than you will have many Messages before ending by max forwards.
Hadriel: proposes to pass thought the Max-Breadth.
Robert:
Andrew: Please not remove Max-Forwards.
Robert: Max Forwards didn't work for proxies.
Others: It works
Robert: Yes better than nothing.
Keith: There are still Scenarios where this will not work. Conclusion à not everything will work.

Conclusion: We will get rid of loops within STRAW.

- - Media-loopback test calls (20 min)
Presenter: Hadriel Kaplan
Related reading: A Media-based Traceroute Function for the Session Initiation Protocol (SIP): http://tools.ietf.org/html/draft-kaplan-dispatch-sip-traceroute-00

Slides-84-straw-4

Draft proposes a new header which is decremented by passing each media aware B2BUA. This is needed for trouble solution.

Brian: Could be useful. But why should this to be implemented?
Hadriel: This is seen more for test calls to trace it.
Martin: This will work within a carrier network, but we will not let others in our network. Such test calls will be only traced border to border.

Paul: Likes the concept but not the new header. Why Max Forwards is not enough. So when M-F=0 the B2BUA can answer the call.
Hadriel: When a loop exists then the B2BUA will answer this but does not help while circulating.

Hadriel: There will be a media loopback RFC soon.
Daryl House: What the difference between this Media loopback and the proposed mechanism.
Hadriel: For test calls to a B2BUA and wanted to have it explicitly answered. E.G. for cases where the Call sucks.

Brian: Problem is that you cannot replicate the path. But do stepwise testing.
Hadriel: No will really will go through the path.
Andrew: No guarantee that this can be replicated, but could help.
Martin: If you have unpredictable results than it will not help.
Brian: will not work 100% but will work in 95% of cases.
Dale: You need not a 100% reproducibility 95% is enough. So if you make 20 Calls you will get at least a result.

Daryl House: Asks if this is really a use case for this WG.
Hadriel: Was asked at least by 2 SP from US

Martin: Really disagrees with the mechanism to. It makes these things worse. Not better, because more measurements and effort are needed with no or minimal result.

Conclusions:

Christer: Not yet asking for adoption but asking for comments on the list and discuss the discussed proposals. E.G definition of other B2BUA roles. Phone call planned not a interims.

Daryl: Asks for discussion of the existing B2BUA roles.
Paul: Proposal to add later also further roles to the draft when definition of existing roles are finalized and agreed.
Conclusion: This means that the draft will be frozen for some of the B2BUA roles but could be extended by new defined roles.

End of Meeting

Mit freundlichen Grüßen; With Best Regards
Roland Jesske

Deutsche Telekom Technik GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 58-12766 (Tel.)
+49 6151 58-13395 (Fax)
+49 171 8618-445 (Mobil)
http://www.telekom.com <http://www.telekom.com/>

Erleben, was verbindet.

Deutsche Telekom Technik GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262

Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.