From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: WG Review: Sip Traversal Required for Applications to Work (straw)
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 <gonzalo.camarillo@ericsson.com>
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
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: straw WG <straw@ietf.org>
Subject: WG Action: Formed Sip Traversal Required for Applications to Work (straw)
A new IETF working group has been formed in the Real-time Applications
and Infrastructure Area. For additional information please contact the
Area Directors or the WG Chairs.
Sip Traversal Required for Applications to Work (straw)
------------------------------------------------
Current Status: Proposed Working Group
Chairs:
Christer Holmberg <christer.holmberg@ericsson.com>
Victor Pascual <vpascual@acmepacket.com>
Assigned Area Director:
Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Mailing list
Address: straw@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/straw
Archive: http://www.ietf.org/mail-archive/web/straw/
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