Subject: Re: [dispatch] STRAW Charter Proposal

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 27 Mar 2012 17:52:38 +0530

I think RTCP has similar issues with B2BUAs and getting RTCP/SRTCP
working end-to-end across B2BUAs, in particular those B2BUAs that
perform transcoding/transrating of media streams, is also important. I
would suggest adding a deliverable for RTCP/SRTCP:

6) A document defining the requirements for B2BUAs to support RTCP/SRTCP
end-to-end.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
|Sent: Tuesday, January 24, 2012 8:16 AM
|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: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Mar 2012 12:39:04 +0000

Umm sure, but just to be clear - if a B2BUA does transcoding it *is* the end of RTCP (and a new RTCP beginning on the other side).  As far as I know, it is illogical to expect RTCP to go "through" a transcoder.

Are you proposing we should have a milestone for documenting specific functionality of RTCP, such as by passing through specific fields of RTCP, that needs to work through a transcoder?

-hadriel

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Mar 2012 15:42:45 +0200

While I'm sure it's more common to terminate RTCP at the transcoder, RTP Translators [RFC3550 section 7.2; Topo-Media-Translator in RFC5117] were intended to support the case where RTCP goes through the transcoder. 

Colin

On 27 Mar 2012, at 14:39, Hadriel Kaplan wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

-- 
Colin Perkins
http://csperkins.org/

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Mar 2012 15:16:32 +0000

As far as I can tell from wireshark captures, some or even many transcoders act as full endpoints, and generate their own RTCP - as if there were a TDM loopback internally - not as RFC 3550 "translators".  I am definitely not an expert in that area, however - is it the case that most transcoders act as translators, or as full endpoints?

Should the taxonomy document for STRAW distinguish between B2BUAs that transcoders as RFC 3550 translators, vs. ones that transcode as full back-to-back media endpoints?

Muthu - did you mean it in that context of a translator?  Or did you mean it in the context of getting RTCP/SRTCP passed through transcoding B2BUAs, without modification? (my impression was you meant passing it through without modification)

-hadriel

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 27 Mar 2012 21:39:37 +0530

Guess I wasn't clear when I said "getting RTCP/SRTCP working end-to-end
across B2BUAs". I only meant getting RTCP working across B2BUAs so that
the endpoints can take useful decisions based on RTCP. I agree there
would be cases like transcoding where a B2BUA would have to terminate
RTCP coming from one side and generate its own RTCP and there would also
be cases where a B2BUA would have to simply pass across RTCP. However,
information like IP addresses carried inside RTCP CNAME might have
impact on B2BUA policies like address hiding when RTCP is passed across.

So, similar to STUN, documenting how a B2BUA should handle RTCP for the
various use cases would be useful I think.

Muthu

|-----Original Message-----
|From: Hadriel Kaplan [mailto:[email-masked]]
|Sent: Tuesday, March 27, 2012 5:17 PM
|To: Colin Perkins; Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked] list
|Subject: Re: [dispatch] STRAW Charter Proposal
|
|
|As far as I can tell from wireshark captures, some or even many
transcoders act as full endpoints, and
|generate their own RTCP - as if there were a TDM loopback internally -
not as RFC 3550 "translators".
|I am definitely not an expert in that area, however - is it the case
that most transcoders act as
|translators, or as full endpoints?
|
|Should the taxonomy document for STRAW distinguish between B2BUAs that
transcoders as RFC 3550
|translators, vs. ones that transcode as full back-to-back media
endpoints?
|
|Muthu - did you mean it in that context of a translator?  Or did you
mean it in the context of getting
|RTCP/SRTCP passed through transcoding B2BUAs, without modification? (my
impression was you meant
|passing it through without modification)
|
|-hadriel
|
|
|On Mar 27, 2012, at 3:42 PM, Colin Perkins wrote:
|
|> While I'm sure it's more common to terminate RTCP at the transcoder,
RTP Translators [RFC3550
|section 7.2; Topo-Media-Translator in RFC5117] were intended to support
the case where RTCP goes
|through the transcoder.
|>
|> Colin
|>
|>
|> On 27 Mar 2012, at 14:39, Hadriel Kaplan wrote:
|>> Umm sure, but just to be clear - if a B2BUA does transcoding it *is*
the end of RTCP (and a new
|RTCP beginning on the other side).  As far as I know, it is illogical
to expect RTCP to go "through" a
|transcoder.
|>>
|>> Are you proposing we should have a milestone for documenting
specific functionality of RTCP, such
|as by passing through specific fields of RTCP, that needs to work
through a transcoder?
|>>
|>> -hadriel
|>>
|>>
|>> On Mar 27, 2012, at 2:22 PM, Muthu Arul Mozhi Perumal (mperumal)
wrote:
|>>
|>>> I think RTCP has similar issues with B2BUAs and getting RTCP/SRTCP
|>>> working end-to-end across B2BUAs, in particular those B2BUAs that
|>>> perform transcoding/transrating of media streams, is also
important. I
|>>> would suggest adding a deliverable for RTCP/SRTCP:
|>>>
|>>> 6) A document defining the requirements for B2BUAs to support
RTCP/SRTCP
|>>> end-to-end.
|>>>
|>>> Muthu
|>>>
|>>> |-----Original Message-----
|>>> |From: [email-masked] [mailto:[email-masked]]
On
|>>> Behalf Of Hadriel Kaplan
|>>> |Sent: Tuesday, January 24, 2012 8:16 AM
|>>> |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
|>>
|>> _______________________________________________
|>> dispatch mailing list
|>> [email-masked]
|>> https://www.ietf.org/mailman/listinfo/dispatch
|>
|>
|> --
|> Colin Perkins
|> http://csperkins.org/
|>
|>
|>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Mar 2012 21:07:53 +0000

Can you suggest milestone text for it?

-hadriel

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 29 Mar 2012 13:40:02 +0530

I see you have already added it in the updated charter and text looks ok
to me. RTCP is probably not as big an issue compared to STUN or
DTLS-SRTP for B2BUAs, however if one of the B2BUAs breaks RTCP it would
be good to have a document to point to what the best current practice
is. It is a way of future proofing RTCP for B2BUA use case, IMHO.

Muthu 

|-----Original Message-----
|From: Hadriel Kaplan [mailto:[email-masked]]
|Sent: Tuesday, March 27, 2012 11:08 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Colin Perkins; <[email-masked]>
|Subject: Re: [dispatch] STRAW Charter Proposal
|
|
|Can you suggest milestone text for it?
|
|-hadriel
|
|
|On Mar 27, 2012, at 6:09 PM, Muthu Arul Mozhi Perumal (mperumal) wrote:
|
|> Guess I wasn't clear when I said "getting RTCP/SRTCP working
end-to-end
|> across B2BUAs". I only meant getting RTCP working across B2BUAs so
that
|> the endpoints can take useful decisions based on RTCP. I agree there
|> would be cases like transcoding where a B2BUA would have to terminate
|> RTCP coming from one side and generate its own RTCP and there would
also
|> be cases where a B2BUA would have to simply pass across RTCP.
However,
|> information like IP addresses carried inside RTCP CNAME might have
|> impact on B2BUA policies like address hiding when RTCP is passed
across.
|>
|> So, similar to STUN, documenting how a B2BUA should handle RTCP for
the
|> various use cases would be useful I think.
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: Hadriel Kaplan [mailto:[email-masked]]
|> |Sent: Tuesday, March 27, 2012 5:17 PM
|> |To: Colin Perkins; Muthu Arul Mozhi Perumal (mperumal)
|> |Cc: [email-masked] list
|> |Subject: Re: [dispatch] STRAW Charter Proposal
|> |
|> |
|> |As far as I can tell from wireshark captures, some or even many
|> transcoders act as full endpoints, and
|> |generate their own RTCP - as if there were a TDM loopback internally
-
|> not as RFC 3550 "translators".
|> |I am definitely not an expert in that area, however - is it the case
|> that most transcoders act as
|> |translators, or as full endpoints?
|> |
|> |Should the taxonomy document for STRAW distinguish between B2BUAs
that
|> transcoders as RFC 3550
|> |translators, vs. ones that transcode as full back-to-back media
|> endpoints?
|> |
|> |Muthu - did you mean it in that context of a translator?  Or did you
|> mean it in the context of getting
|> |RTCP/SRTCP passed through transcoding B2BUAs, without modification?
(my
|> impression was you meant
|> |passing it through without modification)
|> |
|> |-hadriel
|> |
|> |
|> |On Mar 27, 2012, at 3:42 PM, Colin Perkins wrote:
|> |
|> |> While I'm sure it's more common to terminate RTCP at the
transcoder,
|> RTP Translators [RFC3550
|> |section 7.2; Topo-Media-Translator in RFC5117] were intended to
support
|> the case where RTCP goes
|> |through the transcoder.
|> |>
|> |> Colin
|> |>
|> |>
|> |> On 27 Mar 2012, at 14:39, Hadriel Kaplan wrote:
|> |>> Umm sure, but just to be clear - if a B2BUA does transcoding it
*is*
|> the end of RTCP (and a new
|> |RTCP beginning on the other side).  As far as I know, it is
illogical
|> to expect RTCP to go "through" a
|> |transcoder.
|> |>>
|> |>> Are you proposing we should have a milestone for documenting
|> specific functionality of RTCP, such
|> |as by passing through specific fields of RTCP, that needs to work
|> through a transcoder?
|> |>>
|> |>> -hadriel
|> |>>
|> |>>
|> |>> On Mar 27, 2012, at 2:22 PM, Muthu Arul Mozhi Perumal (mperumal)
|> wrote:
|> |>>
|> |>>> I think RTCP has similar issues with B2BUAs and getting
RTCP/SRTCP
|> |>>> working end-to-end across B2BUAs, in particular those B2BUAs
that
|> |>>> perform transcoding/transrating of media streams, is also
|> important. I
|> |>>> would suggest adding a deliverable for RTCP/SRTCP:
|> |>>>
|> |>>> 6) A document defining the requirements for B2BUAs to support
|> RTCP/SRTCP
|> |>>> end-to-end.
|> |>>>
|> |>>> Muthu
|> |>>>
|> |>>> |-----Original Message-----
|> |>>> |From: [email-masked]
[mailto:[email-masked]]
|> On
|> |>>> Behalf Of Hadriel Kaplan
|> |>>> |Sent: Tuesday, January 24, 2012 8:16 AM
|> |>>> |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
|> |>>
|> |>> _______________________________________________
|> |>> dispatch mailing list
|> |>> [email-masked]
|> |>> https://www.ietf.org/mailman/listinfo/dispatch
|> |>
|> |>
|> |> --
|> |> Colin Perkins
|> |> http://csperkins.org/
|> |>
|> |>
|> |>
|>