Subject: [straw] WG Review: Sip Traversal Required for Applications to Work (straw)

From: Mary Barnes <[email-masked]>
Date: Tue, 10 Jul 2012 17:49:40 -0500

---------- Forwarded message ----------
From: Gonzalo Camarillo <[email-masked]>
Date: Tue, Jul 10, 2012 at 3:10 PM
Subject: Re: [dispatch] Fwd: [new-work] WG Review: Sip Traversal Required
for Applications to Work (straw)
To: "[email-masked]" <[email-masked]>

Hi,

the STRAW WG has just been chartered:

https://datatracker.ietf.org/wg/straw/charter/

Cheers,

Gonzalo

On 05/07/2012 11:06 AM, Gonzalo Camarillo wrote:
> Folks,
>
> the IESG will discuss the chartering of this new WG this evening. In the
> mean time, you may want to subscribe to the newly created mailing list
> for the WG.
>
> https://www.ietf.org/mailman/listinfo/straw
>
> Cheers,
>
> Gonzalo
>
> On 26/06/2012 8:06 PM, Victor Pascual Avila wrote:
>> FYI
>>
>> ---------- Forwarded message ----------
>> From: IESG Secretary <[email-masked]>
>> Date: Tue, Jun 26, 2012 at 6:22 PM
>> Subject: [new-work] WG Review: Sip Traversal Required for Applications
>> to Work (straw)
>> To: [email-masked]
>>
>>
>> A new IETF working group has been proposed in the Real-time Applications
>> and Infrastructure Area. The IESG has not made any determination yet. The
>> following draft charter was submitted, and is provided for informational
>> purposes only. Please send your comments to the IESG mailing list (iesg
>> at ietf.org) by 2012-07-03.
>>
>> Sip Traversal Required for Applications to Work (straw)
>> ------------------------------------------------
>> Current Status: Proposed Working Group
>>
>> Assigned Area Director:
>>  Gonzalo Camarillo <[email-masked]>
>>
>>
>> Charter of Working Group:
>>
>> 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
>> (Primary Rate Interface) 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 (Session Border
>> Controlers)or PBXs (Private Branch Exchanges). 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.
>>
>> Milestones:
>>  Dec 2012 - A taxonomy document defining role-types of B2BUAs, as a
>> reference for other deliverables submitted to the IESG as Informational
>>  Apr 2013 - A document defining the requirements for B2BUAs with respect
>> to loop detection/prevention submitted to the IESG as PS
>>  Aug 2013 - A document defining the requirements for B2BUAs to support
>> end-to-end and hop-by-hop media-loopback test calls submitted to the IESG
>> as PS
>>  Dec 2013 - A document defining the requirements for B2BUAs to support
>> DTLS-SRTP (RFC 5764) end-to-end submitted to the IESG as PS
>>  Dec 2013 - A document defining the requirements for B2BUAs to support
>> STUN message transactions end-to-end submitted to the IESG as PS
>>  Dec 2013 - A document defining the requirements for B2BUAs to support
>> RTCP end-to-end submitted to the IESG as PS
>>
>>
>> _______________________________________________
>> new-work mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/new-work
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch