Subject: Re: [dispatch] STRAW Charter Proposal

From: Daryl Malas <[email-masked]>
Date: Tue, 7 Feb 2012 10:18:27 -0700

Hadriel et al,

I support this work, and the result of the work "may" address the issue
Sohel has described regarding SSP loop detection.  We have all discussed
on many occasions how B2BUA's tend to cause challenges in SIP networks.
While we will not be the enforcers of the documents defined here, SSP's
can request compliance.  Compliance will provide them an increased level
of interoperability, troubleshooting and supported SIP functionality (or
UA capability).  

Regards,

Daryl

On 1/24/12 12:15 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>Howdy,
>As instructed by DISPATCH chairs, I am re-posting the STRAW Charter
>Proposal, as a topic for the Paris meeting.
>The proposed charter is as follows:
>
>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. 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 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.
>
>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.
>
>The intention of this WG is to document such requirements in separate
>documents, per SIP or media function, instead of as one document for all
>functions.  That will both reduce the time to publication, as well a
>provide B2BUA administrators and manufacturers with simple
>comply/no-comply criteria.
>
>
>Initial Deliverables:
>1) A taxonomy document defining role-types of B2BUAs, as a reference for
>other deliverables.
>2) A document defining the requirements for B2BUAs with respect to loop
>detection/prevention.
>3) A document defining the requirements for B2BUAs to support end-to-end
>and hop-by-hop media-loopback test calls.
>4) A document defining the requirements for B2BUAs to support DTLS-SRTP
>(RFC 5764) end-to-end.
>5) A document defining the requirements for B2BUAs to support STUN
>connectivity checks end-to-end.
>
>
>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

---

From: Qin Wu <[email-masked]>
Date: Wed, 08 Feb 2012 10:36:50 +0800

+1
The deliverables focusing on requirements are reasonable to me. It seems early to go
to the solution scope given various existing approaches that may work in some cases and
break in others.

I like to see this work going ahead.

Regards!
-Qin

---

From: Rockson Li <[email-masked]>
Date: Wed, 08 Feb 2012 13:15:08 +0800

+1
I support this work.
B2BUA is used a lot in real world.
But there's no any normative documents on its behavior, which causes
numerous interop issue.

-Rockson

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 8 Feb 2012 07:03:43 +0000

+1 I like to see this charter moving forward....

Lot of SIP related RFC are written from SIP UA perspective which is not very clear for B2BUA implementation. We will discuss in detail about the milestone before IETF-83 dispatch meeting

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Rockson Li
>Sent: Wednesday, February 08, 2012 10:45 AM
>To: Qin Wu; Daryl Malas; Hadriel Kaplan; [email-masked]
>>The deliverables focusing on requirements are reasonable to me. It
>>seems early to go to the solution scope given various existing
>>approaches that may work in some cases and break in others.
>>
>>> I support this work, and the result of the work "may" address the
>>> issue Sohel has described regarding SSP loop detection.  We have all
>>> discussed on many occasions how B2BUA's tend to cause challenges in
>SIP networks.
>>> While we will not be the enforcers of the documents defined here,
>>> SSP's can request compliance.  Compliance will provide them an
>>> increased level of interoperability, troubleshooting and supported
>>> SIP functionality (or UA capability).
>>>
>>> Regards,
>>>
>>> Daryl
>>>
>>>>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.
>>>>
>>>>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.
>>>>
>>>>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.
>>>>
>>>>Max-Forwards header field value should be copied and decremented
>>>>across the B2BUA, if the B2BUA wishes to prevent loops.
>>>>Administrators could then tell their B2BUA vendors to comply with the
>>>>document, if the administrator so wishes.
>>>>
>>>>Objectives:
>>>>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.
>>>>
>>>>documents, per SIP or media function, instead of as one document for
>>>>all functions.  That will both reduce the time to publication, as
>>>>well a provide B2BUA administrators and manufacturers with simple
>>>>1) A taxonomy document defining role-types of B2BUAs, as a reference
>>>>for other deliverables.
>>>>2) A document defining the requirements for B2BUAs with respect to
>>>>loop detection/prevention.
>>>>3) A document defining the requirements for B2BUAs to support
>>>>end-to-end and hop-by-hop media-loopback test calls.
>>>>4) A document defining the requirements for B2BUAs to support
>>>>DTLS-SRTP (RFC 5764) end-to-end.

---

From: Hendrik Scholz <[email-masked]>
Date: Wed, 08 Feb 2012 10:19:15 +0100

Hi Hadriel,

+1
I support this work and am happy to contribute.
In addition to the identified work items there could be a document
on 'how to allow custom headers/data to pass through STRAW-enabled B2BUAs'.
The rationale for me is that even if we cannot agree on a SPID mechanism
which may disclose too much private information for some use cases there
may be federations of carriers which want to have this information.
In a nutshell SBCs may be instructed to pass all data in SIP headers
with a (to be defined) STRAW prefix from the UAS to the UAC side and
vice versa.

Cheers,
 Hendrik

-- 
Hendrik Scholz <[email-masked]>

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 8 Feb 2012 15:44:01 +0530

+1

Seems like a stepping stone for what I was trying to advocate back in
2010:
http://www.ietf.org/mail-archive/web/dispatch/current/msg02097.html

Would be happy to contribute..

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
|Sent: Tuesday, January 24, 2012 12:46 PM
|To: [email-masked] list
|Subject: [dispatch] STRAW Charter Proposal
|
|Howdy,
|As instructed by DISPATCH chairs, I am re-posting the STRAW Charter
Proposal, as a topic for the Paris
|meeting.
|The proposed charter is as follows:
|
|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. 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 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.
|
|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.
|
|The intention of this WG is to document such requirements in separate
documents, per SIP or media
|function, instead of as one document for all functions.  That will both
reduce the time to
|publication, as well a provide B2BUA administrators and manufacturers
with simple comply/no-comply
|criteria.
|
|
|Initial Deliverables:
|1) A taxonomy document defining role-types of B2BUAs, as a reference
for other deliverables.
|2) A document defining the requirements for B2BUAs with respect to loop
detection/prevention.
|3) A document defining the requirements for B2BUAs to support
end-to-end and hop-by-hop media-loopback
|test calls.
|4) A document defining the requirements for B2BUAs to support DTLS-SRTP
(RFC 5764) end-to-end.
|5) A document defining the requirements for B2BUAs to support STUN
connectivity checks end-to-end.
|
|
|_______________________________________________
|dispatch mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 21 Feb 2012 15:13:53 +0100

Hi Hadriel / Dispatch,

I like the charter and think that the approach of picking some reasonably manageable topics which cover existing problem areas or areas of current interest is the right approach.

I would be happy to contribute to this work.

Sorry took so long to get round to reading the dispatch list.

Regards
Andy

> Sent: 24 January 2012 07:16
> To: [email-masked] list
> Subject: [dispatch] STRAW Charter Proposal
> 
> Howdy,
> 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
> 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
> 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
> 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.
> 
> bodies, body content fields/information, or media-plane characteristics
> are required to traverse between the User Agent "sides" of a B2BUA for
> For example, a document defining the requirements for end-to-end DTLS-
> SRTP would not apply to B2BUAs which terminate media, such as
> all functions.  That will both reduce the time to publication, as well
> a provide B2BUA administrators and manufacturers with simple comply/no-
> comply criteria.
> 
> 
> Initial Deliverables:
> 3) A document defining the requirements for B2BUAs to support end-to-
> end and hop-by-hop media-loopback test calls.