Subject: [dispatch] Updated STRAW Charter

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Mar 2012 00:47:26 +0000

Howdy,
I have reviewed today's DISPATCH Meetecho recording, and modified the charter as below - I can't attest to it representing everyone's input accurately, so please review it and provide feedback if it does not reflect your wishes.

---------------------------------------------
Major changes:
- removed the paragraph about delivering separate documents of discrete functions
- added a paragraph in objectives about it covering existing work
- removed the deliverable for identifying specific features/capabilities support
- added a deliverable for the taxonomy doc
- added a deliverable for a framework doc
- added a deliverable for end-to-end RTCP
---------------------------------------------

Description of STRAW Working Group
====================================
Name: Sip Traversal Required for Applications to Work (STRAW)

Problem Statement: 
Within the context of the SIP protocol and architecture, a Back-to-Back User Agent (B2BUA) is any SIP device in the logical path between two User Agents performing a role beyond that of a Proxy as defined in RFC 3261.  The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order to terminate dead sessions by generating BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a Session Border Controller performing such functions as in RFC 5853; or it may be an Enterprise PBX terminating REFERs and such; or it may be a complete UAS and UAC implementation with a PRI loopback in-between. 

In its most extreme form, the scope of the SIP protocol ends at the UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In practice, however, users expect some SIP protocol aspects to go beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA was not an end unto itself; this is similar to the expectation that emails work when they cross from POP and IMAP to/from SMTP.

It is impossible to normatively define all the behaviors of B2BUAs in general, or even subsets of them such as SBCs or PBXs. Unlike consumer NATs, B2BUAs perform widely varying functions for purposes which may be unique to their environment, unique to their architecture, or unique to the wishes of their administrator.  Instead of defining all things a given type of B2BUA must do, a more practical objective would be to define what very few things any B2BUA must do to make a specific SIP mechanism work, and let the market decide whether to do those things.

The name of this working group reflects that practical objective: if there were a thin straw between the SIP UAS and UAC of a B2BUA, what must be passed through that straw and used on each side.  Or viewed another way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and if we could extend ISDN, what information would we carry in ISDN across the PRI for a specific SIP mechanism to work end-to-end.

For example, the WG could produce a document which specifies that the Max-Forwards header field value should be copied and decremented across the B2BUA, if the B2BUA wishes to prevent infinite loops.  Administrators could then tell their B2BUA vendors to comply with the document, if the administrator so wishes.

Objectives:
The objectives of the STRAW Working Group are to publish normative documents which define which SIP header fields, parameters, MIME bodies, body content fields/information, or media-plane characteristics are required to traverse between the User Agent "sides" of a B2BUA for specific functions to work.  

The specific functions covered are expected to relate to already-published RFCs or existing RAI area work, as opposed to all future IETF work.  In other words, the Working Group is not meant to be a never-ending source for B2BUA requirements in the RAI area.

Deliverables would indicate which types of B2BUAs would apply or not.  For example, a document defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, such as transcoders or recorders.

Initial Deliverables:
1) A taxonomy document defining role-types of B2BUAs, as a reference for other deliverables.
2) A framework document for future IETF RFCs to use as considerations for their own B2BUA requirements.
3) A document defining the requirements for B2BUAs with respect to loop detection/prevention.
4) A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls.
5) A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end.
6) A document defining the requirements for B2BUAs to support STUN message transactions end-to-end.
7) A document defining the requirements for B2BUAs to support RTCP end-to-end.

---

From: Daryl Malas <[email-masked]>
Date: Wed, 28 Mar 2012 01:43:57 -0600

Hadriel,

Thank you for quickly turning around a new charter.  In general, I'm good
with the proposed changes.  With regards to the "framework" deliverable, I
was envisioning a framework for creating relevant requirements for a B2BUA
AND detailing appropriate text for "considerations" sections of IETF
drafts.  This may apply to unidentified past I-Ds/RFCs or future
I-Ds/RFCs.  With this in mind, I suggest the following change to the
deliverable:

From: "A framework document for future IETF RFCs to use as considerations
for their own B2BUA requirements."

To: "A framework document for defining requirements and considerations for
traversing B2BUAs."

--Daryl

On 3/28/12 2:47 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>Howdy,
>I have reviewed today's DISPATCH Meetecho recording, and modified the
>charter as below - I can't attest to it representing everyone's input
>accurately, so please review it and provide feedback if it does not
>reflect your wishes.
>
>Within the context of the SIP protocol and architecture, a Back-to-Back
>User Agent (B2BUA) is any SIP device in the logical path between two User
>Agents performing a role beyond that of a Proxy as defined in RFC 3261.
>The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA
>in order to terminate dead sessions by generating BYEs; or it may be a
>3PCC-style agent only modifying SDP; or it may be a Session Border
>Controller performing such functions as in RFC 5853; or it may be an
>Enterprise PBX terminating REFERs and such; or it may be a complete UAS
>and UAC implementation with a PRI loopback in-between.
>
>In its most extreme form, the scope of the SIP protocol ends at the UAS
>of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In
>practice, however, users expect some SIP protocol aspects to go beyond
>the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as
>if the B2BUA was not an end unto itself; this is similar to the
>expectation that emails work when they cross from POP and IMAP to/from
>SMTP.
>
>It is impossible to normatively define all the behaviors of B2BUAs in
>general, or even subsets of them such as SBCs or PBXs. Unlike consumer
>NATs, B2BUAs perform widely varying functions for purposes which may be
>unique to their environment, unique to their architecture, or unique to
>the wishes of their administrator.  Instead of defining all things a
>given type of B2BUA must do, a more practical objective would be to
>define what very few things any B2BUA must do to make a specific SIP
>mechanism work, and let the market decide whether to do those things.
>
>The name of this working group reflects that practical objective: if
>there were a thin straw between the SIP UAS and UAC of a B2BUA, what must
>be passed through that straw and used on each side.  Or viewed another
>way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback
>circuit, and if we could extend ISDN, what information would we carry in
>ISDN across the PRI for a specific SIP mechanism to work end-to-end.
>
>For example, the WG could produce a document which specifies that the
>Max-Forwards header field value should be copied and decremented across
>the B2BUA, if the B2BUA wishes to prevent infinite loops.  Administrators
>could then tell their B2BUA vendors to comply with the document, if the
>administrator so wishes.
>
>
>Objectives:
>The objectives of the STRAW Working Group are to publish normative
>documents which define which SIP header fields, parameters, MIME bodies,
>body content fields/information, or media-plane characteristics are
>required to traverse between the User Agent "sides" of a B2BUA for
>specific functions to work.
>
>The specific functions covered are expected to relate to
>already-published RFCs or existing RAI area work, as opposed to all
>future IETF work.  In other words, the Working Group is not meant to be a
>never-ending source for B2BUA requirements in the RAI area.
>
>Deliverables would indicate which types of B2BUAs would apply or not.
>For example, a document defining the requirements for end-to-end
>DTLS-SRTP would not apply to B2BUAs which terminate media, such as
>transcoders or recorders.
>
>
>Initial Deliverables:
>4) A document defining the requirements for B2BUAs to support end-to-end
>and hop-by-hop media-loopback test calls.
>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Mar 2012 10:57:33 +0000

Works for me - anyone object?

-hadriel