From D.Hancock@CableLabs.com Tue Nov 3 15:10:29 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95D93A6869 for ; Tue, 3 Nov 2009 15:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.765 X-Spam-Level: X-Spam-Status: No, score=0.765 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1178jWXZalKR for ; Tue, 3 Nov 2009 15:10:25 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 3A2D13A67F1 for ; Tue, 3 Nov 2009 15:10:25 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id nA3NAkb3008746 for ; Tue, 3 Nov 2009 16:10:46 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 3 Nov 2009 16:10:46 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5CDA.DFCD1E0F" Date: Tue, 3 Nov 2009 16:10:45 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6026450A8@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Speermint] draft-hancock-sip-interconnect-guidelines to a WG item? Thread-Index: Acpc2t99B9MkziHBQxmxYj9VbBDdiw== From: "David Hancock" To: X-Approved: ondar Subject: Re: [Speermint] draft-hancock-sip-interconnect-guidelines to a WG item? X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 23:10:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5CDA.DFCD1E0F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Victor, =20 I don't have any objection to adding this, but would like to better understand the use-cases/call-types that might use this extension. For example, is this extension used within the scope of the basic call types & features currently listed in section-1.1, or do I need to increase the scope? Does everyone agree with this scope-increase?=20 =20 Also, do you think support should be mandatory or optional? For example, do you think the sending SBE to include the 'resource-priority' option tag in the Supported header of every message? If support is optional, what should the draft say about this extension? =20 Thanks David =20 =20 =20 Subject: Re: [Speermint] draft-hancock-sip-interconnect-guidelines to a WG item?=20 From: Victor Pascual Avila >=20 Date: Tue, 27 Oct 2009 16:14:46 +0100 =20 While "emergency calls" is not addressed in the document, IMHO it would be useful to define whether the Resource-Priority header field should be honored, specially in section 4.5.2 =20 Thanks, -Victor =20 On Mon, Oct 26, 2009 at 8:29 PM, Jason Livingood wrote: > At the last meeting we had a request to make > draft-hancock-sip-interconnect-guidelines-01 an official working group item. > I didn't hear any loud objections to that but wanted to ask again here. If > you have any concerns about whether this should become a WG, please advise. >=20 > Thanks > Jason > _______________________________________________ > Speermint mailing list > Speermint at ietf.org > https://www.ietf.org/mailman/listinfo/speermint >=20 >=20 =20 =20 ------_=_NextPart_001_01CA5CDA.DFCD1E0F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Victor,

 = ;

I don’t have any objection to adding this, but would like to better understand the use-cases/call-types that might use this extension. For = example, is this extension used within the scope of the basic call types & = features currently listed in section-1.1, or do I need to increase the scope? = Does everyone agree with this scope-increase? =

 = ;

Also, do you think support should be mandatory or optional? For example, do = you think the sending SBE to include the 'resource-priority' option tag in the = Supported header of every message?  If support is optional, what should the = draft say about this extension?

 = ;

Thanks

David

 

 

 

Subject: Re: = [Speermint] draft-hancock-sip-interconnect-guidelines to a WG item?

From: Victor Pascual Avila <victor.pascual.avila at gmail.com> 

Date: Tue, 27 Oct 2009 =
16:14:46 +0100
 
While =
"emergency calls" is not addressed in the document, IMHO =
it
would be =
useful to define whether the Resource-Priority header =
field
should be =
honored, specially in section =
4.5.2
 
Thanks,
-Victor
 
On Mon, =
Oct 26, 2009 at 8:29 PM, Jason =
Livingood
<jason_livingood at cable.comcast.com> =
wrote:
> At =
the last meeting we had a request to =
make
> =
draft-hancock-sip-interconnect-guidelines-01 an official working group =
item.
> =
 I didn’t hear any loud objections to that but wanted to ask =
again here.  If
> you =
have any concerns about whether this should become a WG, please =
advise.
> 
=
> =
Thanks
> =
Jason
> =
_______________________________________________<=
/pre>
> =
Speermint mailing list
> =
Speermint at ietf.org
> https://www.ietf=
.org/mailman/listinfo/speermint
> 
=
> 
=
 



 
------_=_NextPart_001_01CA5CDA.DFCD1E0F-- From D.Hancock@CableLabs.com Wed Nov 4 14:18:47 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C6A3A688D for ; Wed, 4 Nov 2009 14:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.086 X-Spam-Level: X-Spam-Status: No, score=0.086 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0CkRXTYqpw0 for ; Wed, 4 Nov 2009 14:18:37 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 6EB013A6925 for ; Wed, 4 Nov 2009 14:18:37 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id nA4MIwX6010951 for ; Wed, 4 Nov 2009 15:18:59 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 4 Nov 2009 15:18:58 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5D9C.CE45BD8C" Date: Wed, 4 Nov 2009 15:18:58 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C602645145@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of v01->v02 updates to draft-hancock-sip-interconnect-guidelines Thread-Index: AcpdnM3tP75I5wcIQdmlCng4/BcAOg== From: "David Hancock" To: X-Approved: ondar Subject: [Speermint] Summary of v01->v02 updates to draft-hancock-sip-interconnect-guidelines X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 22:18:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5D9C.CE45BD8C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Here is a summary of the major updates between v01 and v02 of the draft-hancock-sip-interconnect-guidelines. =20 -------------------------------------------------- Comment-1: Expand scope to include enterprise peering (John Elwell): =20 Resolution: Added following sentence to section 1... =20 "This document describes the SIP interconnect procedures between two SIP-based networks for both peering SIP Service Providers networks and peering Enterprise networks." =20 -------------------------------------------------- Comment-2: Expand scope to include video and RTT media types (Gunnar Hellstrom, Hadriel Kaplan) =20 Resolution: Updated sections 1.1 and 5.1.1 to allow multiple media types. =20 -------------------------------------------------- Comment-3: Be more specific and consistent when identifying the entity that is responsible for meeting the peering requirements. For example, current text places requirements on a variety of entities, such as "originating network", or "SIP UA" - entities that are not defined as part of the Speermint architecture. (John Elwell) =20 Resolution: Placed requirements on the SBE and DBE throughout document. One slight problem with this approach is that the SBE (for example) can play the role of a firewall or a SIP proxy that is largely transparent to SIP messages crossing the peering interface. It doesn't make sense to put SIP requirements on an SBE acting as a firewall. Therefore, added text to section 3 that expands the definition of SBE slightly (only within the scope of this document) so that when it is specified as the target entity of a normative requirement on the SIP/SDP peering interface, the SBE represents all the SIP entities in the SIP signaling chain that can effect the SIP/SDP peering interface. Made a similar local definition change to the DBE. =20 =20 -------------------------------------------------- Comment-4: Align section 4.1 "Extension Negotiation" text with RFC 3261.=20 =20 Also, text says that SBE can remove extensions from the Supported header. Why not exchange Supported headers transparently, and let both ends negotiate what extensions are used using RFC 3261 procedures? This would allow operators to deploy new extensions without impacting the interface. (Comment from IETF#75 Speermint session) =20 Background: The reason for having the SBE remove an extension from the Supported header was to cater to the situation where an endpoint supports an extension (and puts it in Supported header), but the operator doesn't want the extension used. For example, an operator deploys SIP endpoints that support PRACK. However, on receiving an INVITE containing '100rel' in the Supported header, the terminating peer network always sends responses reliably, which increases per-call message traffic and affects scaling. Therefore, the home operator wants to remove '100rel' from Supported header, so calls are established without PRACK.=20 =20 Resolution: Reworded section 4.1 text as follows... "The SBE MUST identify all supported SIP extensions in the Supported header. The SBE MAY support configuration controls to disable certain extensions based on bilateral agreement between peer networks. For example, the SBE could be configured to remove '100rel' from the Supported header in order to disable the use of reliable provisionable response (PRACK)." =20 -------------------------------------------------- Comment-5: Current text in section 5.1.2 "Basic Call Setup" implies that all INVITEs MUST contain SDP, which would prevent the use of 3PCC to establish calls (since 3PCC procedures send INVITE's with no SDP). (John Elwell) =20 Resolution: Agree that 3PCC should be supported. Therefore, added text to 5.1.2 that says this section covers basic call setup for the non-3PCC case. Added new section 5.1.5 to cover session establishment using 3PCC. =20 -------------------------------------------------- Comment-6: The Media Anchor (section 5.1.2.3.1) and Early Answer (section 5.1.2.3.2) mechanism for providing early media from multi terminating endpoints is not right (John Elwell, Hadriel Kaplan). Also, 302-Redirect can be used to support his case (John Elwell). =20 Resolution: Sections 5.1.2.3.1 & 2 were added to describe mechanisms currently deployed to support this use-case. However, these mechanisms basically hide the issue and make the call look like a normal 2-way call (and therefore don't impact the peering interface). Therefore, they were removed, and the overall section was re-organized to reduce section numbering depth. Also, added a new section 5.1.4.2 to describe the Redirect mechanism. =20 -------------------------------------------------- Comment-7: How is History-Info used to support call-forwarding loop detection? Also, H-I support may not be sufficiently ubiquitous to serve as a good solution. Aren't there other mechanisms that can be used, such as Diversion header, or Max-Forwards header? (Hadriel Kaplan, plus discussion at IETF#75) =20 Resolution: Based on the discussion, there seems to be no good, well understood and universally supported solution for call-fwd loop detection. However, the draft authors believe that support of call-forward loop-detection is critical, and that the draft should provide some guidance on a standard way to support it at the peering interface. Therefore, added a new section 5.3.1 that a) mandates that the SBE MUST detect call-fwd loops, and b) must reject a call that when the number of times it has been forwarded exceeds a configurable limit. The section then gives some latitude on how this is done, but describes one way using the History-Info header. If an SBE supports the H-I mechanism, then it MUST do it as described in this section.=20 =20 Question to Speermint members: is the above approach in the right direction? Does the described H-I solution solve the problem, and should we mandate that as the one-and-only standard (possibly with more detail)? The idea would be - you can track call-forwarding loops using any mechanism you want inside your network, but at the peering interface you have to use the H-I header. Or, should the draft describe multiple solution options, and describe how they interwork? =20 -------------------------------------------------- Comment-8: It's not clear how the dialog-even package is used to support auto-recall/callback. (Hadriel Kaplan) =20 Response: The BLISS WG is working on a new draft-ietf-bliss-call-completion that defines a new event-package for support of auto-recall/callback. However, this is still a work-in-progress and therefore not ready to be referenced by this interconnect-guidelines draft. In the meantime, the authors propose that the already-defined dialog-event package can be used to provide 90% of the AC/AR functionality. Therefore, text was added to section 5.6 to more fully describe the dialog-event package solution. -------------------------------------------------- =20 Thanks David=20 ------_=_NextPart_001_01CA5D9C.CE45BD8C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Here is a summary = of the major=20 updates between v01 and v02 of = the=20 draft-hancock-sip-interconnect-guidelines.

 

--------------------------------------------------

Comment-1:

Expand scope to include enterprise peering (John=20 Elwell):

 

Resolution:

Added following sentence to section = 1…

 

“This document describes the SIP interconnect procedures = between two=20 SIP-based networks for both peering SIP Service Providers networks and = peering=20 Enterprise=20 networks.”

 

--------------------------------------------------

Comment-2:

Expand scope to include video and RTT media types (Gunnar = Hellstrom,=20 Hadriel Kaplan)

 

Resolution:

Updated sections 1.1 and 5.1.1 to allow multiple media=20 types.

 

--------------------------------------------------

Comment-3:

Be more specific and consistent when identifying the entity = that is=20 responsible for meeting the peering requirements. For example, current = text=20 places requirements on a variety of entities, such as “originating = network”, or=20 “SIP UA” – entities that are not defined as part of = the Speermint architecture.=20 (John Elwell)

 

Resolution:

Placed requirements on the SBE and DBE throughout document. One = slight=20 problem with this approach is that the SBE (for example) can play the = role of a=20 firewall or a SIP proxy that is largely transparent to SIP messages = crossing the=20 peering interface. It doesn’t make sense to put SIP requirements = on an SBE=20 acting as a firewall. Therefore, added text to section 3 that expands = the=20 definition of SBE slightly (only within the scope of this document) so = that when=20 it is specified as the target entity of a normative requirement on the = SIP/SDP=20 peering interface, the SBE represents all the SIP entities in the SIP = signaling=20 chain that can effect the SIP/SDP peering interface. Made a similar = local=20 definition change to the DBE.  

 

--------------------------------------------------

Comment-4:

Align section 4.1 “Extension Negotiation” text with = RFC 3261.

 

Also, text says that SBE can remove extensions from the = Supported header.=20 Why not exchange Supported headers transparently, and let both ends = negotiate=20 what extensions are used using RFC 3261 procedures? This would allow = operators=20 to deploy new extensions without impacting the interface. (Comment from = IETF#75=20 Speermint session)

 

Background:

The reason for having the SBE remove an extension from the = Supported=20 header was to cater to the situation where an endpoint supports an = extension=20 (and puts it in Supported header), but the operator doesn’t want = the extension=20 used. For example, an operator deploys SIP endpoints that support PRACK. = However, on receiving an INVITE containing ‘100rel’ in the = Supported header, the=20 terminating peer network always sends responses reliably, which = increases=20 per-call message traffic and affects scaling. Therefore, the home = operator wants=20 to remove ’100rel’ from Supported header, so calls are = established without=20 PRACK.

 

Resolution:

Reworded section 4.1 text as follows...

“The SBE MUST identify all supported SIP extensions in = the Supported=20 header. The SBE MAY support configuration controls to disable certain = extensions=20 based on bilateral agreement between peer networks.  For example, the SBE could be = configured=20 to remove '100rel' from the Supported header in order to disable the use = of=20 reliable provisionable response (PRACK).”

 

--------------------------------------------------

Comment-5:

Current text in section 5.1.2 “Basic Call Setup” = implies that all INVITEs=20 MUST contain SDP, which would prevent the use of 3PCC to establish calls = (since=20 3PCC procedures send INVITE’s with no SDP). (John = Elwell)

 

Resolution:

Agree that 3PCC should be supported. Therefore, added text to = 5.1.2 that=20 says this section covers basic call setup for the non-3PCC case. Added = new=20 section 5.1.5 to cover session establishment using 3PCC.

 

--------------------------------------------------

Comment-6:

The Media Anchor (section 5.1.2.3.1) and Early Answer (section = 5.1.2.3.2)=20 mechanism for providing early media from multi terminating endpoints is = not=20 right (John Elwell, Hadriel Kaplan). Also, 302-Redirect can be used to = support=20 his case (John Elwell).

 

Resolution:

Sections 5.1.2.3.1 & 2 were added to describe mechanisms = currently=20 deployed to support this use-case. However, these mechanisms basically = hide the=20 issue and make the call look like a normal 2-way call (and therefore = don’t=20 impact the peering interface). Therefore, they were removed, and the = overall=20 section was re-organized to reduce section numbering depth. Also, added = a new=20 section 5.1.4.2 to describe the Redirect mechanism.

 

--------------------------------------------------

Comment-7:

How is History-Info used to support call-forwarding loop = detection? Also,=20 H-I support may not be sufficiently ubiquitous to serve as a good = solution.=20 Aren’t there other mechanisms that can be used, such as Diversion = header, or=20 Max-Forwards header? (Hadriel Kaplan, plus discussion at = IETF#75)

 

Resolution:

Based on the discussion, there seems to be no good, well = understood and=20 universally supported solution for call-fwd loop detection. However, the = draft=20 authors believe that support of call-forward loop-detection is critical, = and=20 that the draft should provide some guidance on a standard way to support = it at=20 the peering interface. Therefore, added a new section 5.3.1 that a) = mandates=20 that the SBE MUST detect call-fwd loops, and b) must reject a call that = when the=20 number of times it has been forwarded exceeds a configurable limit. The = section=20 then gives some latitude on how this is done, but describes one way = using the=20 History-Info header. If an SBE supports the H-I mechanism, then it MUST = do it as=20 described in this section.

 

Question to Speermint members: is the above approach in the = right=20 direction? Does the described H-I solution solve the problem, and should = we=20 mandate that as the one-and-only standard (possibly with more detail)? = The idea=20 would be – you can track call-forwarding loops using any mechanism = you want=20 inside your network, but at the peering interface you have to use the = H-I=20 header. Or, should the draft describe multiple solution options, and = describe=20 how they interwork?

 

--------------------------------------------------

Comment-8:

It’s not clear how the dialog-even package is used to = support=20 auto-recall/callback. (Hadriel Kaplan)

 

Response:

The BLISS WG is working on a new = draft-ietf-bliss-call-completion that=20 defines a new event-package for support of auto-recall/callback. = However, this=20 is still a work-in-progress and therefore not ready to be referenced by = this=20 interconnect-guidelines draft. In the meantime, the authors propose that = the=20 already-defined dialog-event package can be used to provide 90% of the = AC/AR=20 functionality. Therefore, text was added to section 5.6 to more fully = describe=20 the dialog-event package solution.

--------------------------------------------------

 

Thanks

David 

------_=_NextPart_001_01CA5D9C.CE45BD8C-- From jason_livingood@cable.comcast.com Mon Nov 9 20:12:55 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA5D28B56A for ; Mon, 9 Nov 2009 20:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-4.699, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwktTyvTrOFq for ; Mon, 9 Nov 2009 20:12:34 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 2FF7F3A6822 for ; Mon, 9 Nov 2009 20:12:34 -0800 (PST) Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.82165313; Mon, 09 Nov 2009 23:12:40 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 23:12:40 -0500 Received: from 133.93.17.128 ([133.93.17.128]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 10 Nov 2009 04:12:40 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 10 Nov 2009 13:12:35 +0900 From: Jason Livingood To: Message-ID: Thread-Topic: Current -08 Architecture Draft Thread-Index: AcphvAgImeRbdYiQ/0OK3LrIVYdhOw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340703556_372928" X-OriginalArrivalTime: 10 Nov 2009 04:12:40.0979 (UTC) FILETIME=[0B98CE30:01CA61BC] X-Mailman-Approved-At: Mon, 09 Nov 2009 20:15:33 -0800 Subject: [Speermint] Current -08 Architecture Draft X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:12:55 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3340703556_372928 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable SPEERMINT Peering Architecture draft-ietf-speermint-architecture-09 Status of this Memo =20 This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. =20 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. =20 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." =20 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. =20 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. =20 This Internet-Draft will expire on May 26, 2010. =20 Copyright Notice =20 Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. =20 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License." =20 =20 Abstract This document defines the SPEERMINT peering architecture, its functional components and peering interface functions. It also describes the steps taken to establish a session between two peering domains in the context of the functions defined. Table of Contents =20 1. Introduction. 2 2. Reference SPEERMINT Architecture. 4 3. Procedures of Inter-domain SSP Session Establishment. 4 3.1. Relationships between functions/elements... 5 4. Recommended SSP Procedures. 5 4.1. Originating SSP Procedures... 5 4.1.1. The Look-Up Function (LUF) 5 4.1.1.1. Target Address Analysis.. 6 4.1.1.2. ENUM Lookup.. 6 4.1.2. Location Routing Function (LRF) 6 4.1.2.1. DNS Resolution.. 7 4.1.2.2. Routing Table.. 7 4.1.2.3. LRF to LRF Routing.. 7 4.1.3. The Signaling Path Border Element (SBE) 7 4.1.3.1. Establishing a Trusted Relationship.. 8 4.1.3.2. Sending the SIP request.. 8 4.2. Target SSP Procedures... 8 4.2.1. The Ingress Signaling Path Border Element (SBE) 8 4.2.1.1. TLS.. 8 4.2.1.2. Receive SIP requests.. 9 4.3. Data Path Border Element (DBE)... 9 5. Address space considerations. 9 6. Security Considerations. 9 7. IANA Considerations. 10 8. Acknowledgments. 10 9. References. 11 9.1. Normative References... 11 9.2. Informative References... 12 Author's Addresses. 13 =20 =20 1. Introduction =20 The objective of this document is to define a reference peering architectur= e in the context of Session PEERing for Multimedia INTerconnect (SPEERMINT). In this process, we define the peering reference architecture, its functional components, and peering interface functions from the perspective of a SIP Service provider=B9s (SSP) network. This architecture allows the interconnection of two SSPs in layer 5 peering as defined in the SPEERMINT Requirements [14] and Terminology [13] documents. Layer 3 peering is outside the scope of this document. Hence, the figures i= n this document do not show routers so that the focus is on Layer 5 protocol aspects. =20 This document uses terminology defined in the SPEERMINT Terminology documen= t [13], so the reader should be familiar with all the terms defined there. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. =20 2. Reference SPEERMINT Architecture Figure 2 depicts the SPEERMINT architecture and logical functions that form the peering between two SSPs. =20 --------------- --------------- / \ / \ | +--LUF-+ | +------+ | +--LUF-+ | | |->| | | | ENUM | | | |<-| | | | | +------------>| TN DB|<------------+ | | | | | | | | +------+ | | | | | | | +------+ | | +------+ | | | | | | | | | | +--LRF-+ | +--------+ | +--LRF-+ | | | |->| | | | DNS | | | |<-| | | | | +----------->|IP Addrs|<-----------+ | | | | | | | | +--------+ | | | | | | | +------+ | | +------+ | | | | | | | | | | | | | | | | +-------+ +-------+ | | | ----------->| | | |<----------- | | | SBE |<------------>| SBE | | | | | | | | | +-------+ +-------+ | | SSP1 | | SSP2 | | +-------+ +-------+ | | | | | | | | | DBE |<------------>| DBE | | | | | | | | | +-------+ +-------+ | \ / \ / --------------- --------------- Figure 1: Reference SPEERMINT Architecture =20 For further details on the elements and functions described in this figure, please refer to [RFC 5486]. =20 3. Procedures of Inter-domain SSP Session Establishment This document assumes that in order for a session to be established from a UA in the Originating SSP=B9s network to an UA in the Target SSP=B9s network th= e following steps are taken: 1. Determine the target SSP via the LUF. a. If the target address represents an intra-SSP resource, the behavior is out-of-scope with respect to this draft. 2. Determine the address of the SF of the target SSP via the LRF. 3. Establish the session 4. Exchange the media, which could include voice, video, tec, etc. 5. End the session (BYE) The originating SSP would likely perform steps 1-4, and the target SSP woul= d likely perform steps 4-5. In the case the target SSP changes, then steps 1-4 would be repeated. This is reflected in Figure 2 that shows the target SSP with its own peering functions.=20 3.1. Relationships between functions/elements - An SBE can contain a SF function. - An SF can perform LUF and LRF functions. - As an additional consideration, a Session Border Controller [SBC RFC], can contain an SF, SBE and DBE, and may perform the LUF and LRF functions. - The following functions can communicate as follows, depending upon various real-world implementations: o SF can communicate with LUF, LRF, SBE and SF o LUF can communicator with SF and SBE o LRF can communicate with SF and SBE 4. Recommended SSP Procedures This section describes the functions in more detail and provides some recommendations on the role they would play in a SIP call in a Layer 5 peering scenario.=20 Some of the information in the section is taken from [14] and is put here for continuity purposes. 4.1. Originating SSP Procedures 4.1.1. The Look-Up Function (LUF) Purpose is to determine the SF of the target domain of a given request and optionally develop Session Establishment Data. 4.1.1.1. Target Address Analysis When the originating SSP receives a request to communicate, it analyzes the target URI to determine whether the call needs to be routed internal or external to its network. The analysis method is internal to the SSP; thus, outside the scope of SPEERMINT. If the target address does not represent a resource inside the originating SSP=B9s administrative domain or federation of domains, then the originating SSP performs a Lookup Function (LUF) to determine a target address, and the= n is resolves the call routing data by using the Location routing Function (LRF).=20 For example, if the request to communicate is for an im: or pres: URI type, the originating SSP follows the procedures in [8]. If the highest priority supported URI scheme is sip: or sips: the originating SSP skips to SIP DNS resolution in Section 5.1.3. Likewise, if the target address is already a sip: or sips: URI in an external domain, the originating SSP skips to SIP DNS resolution in Section 4.1.2.1. If the target address corresponds to a specific E.164 address, the SSP may need to perform some form of number plan mapping according to local policy. For example, in the United States, a dial string beginning "011 44" could b= e converted to "+44", or in the United Kingdom "00 1" could be converted to "+1". Once the SSP has an E.164 address, it can use ENUM. =20 4.1.1.2. ENUM Lookup If an external E.164 address is the target, the originating SSP consults th= e public "User ENUM" rooted at e164.arpa, according to the procedures described in RFC 3761. The SSP must query for the "E2U+sip" enumservice as described in RFC 3764 [11], but MAY check for other enumservices. The originating SSP MAY consult a cache or alternate representation of the ENUM data rather than actual DNS queries. Also, the SSP may skip actual DNS queries if the originating SSP is sure that the target address country code is not represented in e164.arpa. If a sip: or sips: URI is chosen the SSP skips to Section 5.1.6. If an im: or pres: URI is chosen for based on an "E2U+im" [8] or "E2U+pres" [9] enumserver, the SSP follows the procedures for resolving these URIs to URIs for specific protocols such a SIP or XMPP as described in the previous section.=20 =20 4.1.2. Location Routing Function (LRF) The LRF of an Originating SSP analyzes target address and target domain identified by the LUF, and discovers the next hop signaling function (SF) i= n a peering relationship. The resource to determine the SF of the target domain might be provided by a third-party as in the assisted-peering case. The following sections define mechanisms which may be used by the LRF. Thes= e are not in any particular order and, importantly, not all of them may be used. =20 4.1.2.1. DNS Resolution The originating SSP uses the procedures in RFC 3263 [4] Section 4 to determine how to contact the receiving SSP. To summarize the RFC 3263 procedure: unless these are explicitly encoded in the target URI, a transport is chosen using NAPTR records, a port is chosen using SRV records= , and an address is chosen using A or AAAA records. When communicating with another SSP, entities compliant to this document should select a TLS-protected transport for communication from the originating SSP to the receiving SSP if available. =20 4.1.2.2. Routing Table If there are no End User ENUM records and the Originating SSP cannot discover the carrier-of-record or if the Originating SSP cannot reach the carrier-of-record via SIP peering, the Originating SSP may deliver the call to the PSTN or reject it. Note that the originating SSP may forward the call to another SSP for PSTN gateway termination by prior arrangement using the routing table.=20 If so, the originating SSP rewrites the Request-URI to address the gateway resource in the target SSP's domain and MAY forward the request on to that SSP using the procedures described in the remainder of these steps. 4.1.2.3. LRF to LRF Routing Communications between the LRF of two interconnecting SSPs may use DNS or statically provisioned IP Addresses for reachability. Other inputs to determine the path may be code-based routing, method-based routing, Time of day, least cost and/or source-based routing. 4.1.3. The Signaling Path Border Element (SBE) The purpose of signaling function is to perform routing of SIP messages as well as optionally implement security and policies on SIP messages, and to assist in discovery/exchange of parameters to be used by the Media Function (MF).=20 The signaling function performs the routing of SIP messages. The optional termination and re-initiation of calls may be performed by the signaling path Session Border Element (SBE), or other signaling elements. Optionally, a SF may perform additional functions such as Session Admission Control, SIP Denial of Service protection, SIP Topology Hiding, SIP header normalization, SIP security, privacy, and encryption. The SF of a SBE can also process SDP payloads for media information such as media type, bandwidth, and type of codec; then, communicate this informatio= n to the media function. Signaling function may optionally communicate with the network to pass Layer 3 related policies [10] 4.1.3.1. Establishing a Trusted Relationship Depending on the security needs and trust relationships between SSPs, different security mechanism can be used to establish SIP calls. These are discussed in the following subsections. 4.1.3.1.1. IPSec=20 In certain deployments the use of IPSec between the signaling functions of the originating and terminating domains can be used as a security mechanism instead of TLS. =20 4.1.3.1.2. Co-Location In this scenario the SFs are co-located in a physically secure location and/or are members of a segregated network. In this case messages between the originating and terminating SSPs would be sent as clear text. 4.1.3.2. Sending the SIP request Once a trust relationship between the peers is established, the originating SSP sends the request. =20 4.2. Target SSP Procedures 4.2.1. The Ingress Signaling Path Border Element (SBE) 4.2.1.1. TLS=20 When the receiving SSP receives a TLS client hello, it responds with its certificate. The Target SSP certificate should be valid and rooted in a well-known certificate authority. The procedures to authenticate the SSP=B9s originating domain are specified in [24]. The SF of the Target SSP verifies that the Identity header is valid, corresponds to the message, corresponds to the Identity-Info header, and that the domain in the From header corresponds to one of the domains in the TLS client certificate. 4.2.1.2. Receive SIP requests Once a trust relationship is established, the Target SSP is prepared to receive incoming SIP requests. For new requests (dialog forming or not) th= e receiving SSP verifies if the target (request-URI) is a domain that for which it is responsible. For these requests, there should be no remaining Route header field values. For in-dialog requests, the receiving SSP can verify that it corresponds to the top-most Route header field value. The receiving SSP may reject incoming requests due to local policy. When a request is rejected because the originating SSP is not authorized to peer, the receiving SSP should respond with a 403 response with the reason phrase "Unsupported Peer". 4.3. Data Path Border Element (DBE) The purpose of the DBE [RFC 5486] is to perform media related functions suc= h as media transcoding and media security implementation between two SSPs. An Example of this is to transform a voice payload from one codec (e.g., G.711) to another (e.g., EvRC). Additionally, the MF may perform media relaying, media security, privacy, and encryption. =20 5. Address space considerations =20 Peering must occur in a common IP address space, which is defined by the federation, which may be entirely on the public Internet, or some private address space. The origination or termination networks may or may not entirely be in the same address space. If they are not, then a network address translation (NAT) or similar may be needed before the signaling or media is presented correctly to the federation. The only requirement is tha= t all associated entities across the peering interface are reachable. =20 6. Security Considerations =20 In all cases, cryptographic-based security should be maintained as an optional requirement between peering providers conditioned on the presence or absence of underlying physical security of SSP connections, e.g. within the same secure physical building. In order to maintain a consistent approach, unique and specialized security requirements common for the majority of peering relationships, should be standardized within the IETF. These standardized methods may enable capabilities such as dynamic peering relationships across publicly maintained interconnections. 7. IANA Considerations There are no IANA considerations at this time. =20 8. Acknowledgments=20 The working group thanks Sohel Khan for his initial architecture draft that helped to initiate work on this draft. =20 A significant portion of this draft is taken from [14] with permission from the author R. Mahy. The other important contributor is Otmar Lendl. Special thanks to Jim McEachern for detailed comments and feedback. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.=20 [7] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004. [8] Peterson, J., "Address Resolution for Instant Messaging and Presence",RFC 3861, August 2004. [9] Peterson, J., "Telephone Number Mapping (ENUM) Service Registratio= n for Presence Services", RFC 3953, January 2005. [10] ETSI TS 102 333: " Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Gate control protocol".=20 [11] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. [12] Livingood, J. and R. Shockey, "IANA Registration for an Enumservice Containing PSTN Signaling Information", RFC 4769, November 2006= . 9.2. Informative References [13] Malas, D., "SPEERMINT Terminology", draft-ietf-speermint-terminology-16 (work in progress), February 2008. [14] Mule, J-F., "SPEERMINT Requirements for SIP-based VoIP Interconnection", draft-ietf-speermint-requirements-04.txt, February 2008. [15] Mahy, R., "A Minimalist Approach to Direct Peering", draft- mahy-speermint-direct-peering-02.txt, July 2007. [16] Penno, R., et al., "SPEERMINT Routing Architecture Message Flows", draft-ietf-speermint-flows-02.txt", April 2007. [17] Houri, A., et al., "RTC Provisioning Requirements", draft- houri-speermint-rtc-provisioning-reqs-00.txt, June, 2006. [18] Habler, M., et al., "A Federation based VOIP Peering Architecture", draft-lendl-speermint-federations-03.txt, September 2006. [19] Mahy, R., "A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services", draft-ietf- enum-im-service-03 (work in progress), March 2006. [20] Haberler, M. and R. Stastny, "Combined User and Carrier ENUM in the e164.arpa tree", draft-haberler-carrier-enum-03 (work in progress), March 2006.=20 [21] Penno, R., Malas D., and Melampy, P., "A Session Initiation Protocol (SIP) Event package for Peering", draft-penno-sipping-peering-package-00 (work in progress), September 2006. [22] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", W3C RE= C REC-xml-names-19990114, January 1999. [23] Burger, E (Ed.), "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006 [24] Gurbani, V., Lawrence, S., and B. Laboratories, "Domain Certificate= s in the Session Initiation Protocol (SIP)", draft-ietf-sip-domain-certs-00 (work in progress), November 2007. Author's Addresses Adam Uzelac=20 Global Crossing=20 Rochester, NY - USA Email: adam.uzelac@globalcrossing.com =20 Reinaldo Penno Juniper Networks=20 Sunnyvale, CA - USA Email: rpenno@juniper.net =20 Mike Hammer=20 Cisco Systems=20 Herndon, VA - USA Email: mhammer@cisco.com =20 Sohel Khan, Ph.D.=20 Comcast Cable Communications USA Email: sohel_khan@cable.comcast.com =20 Daryl Malas=20 CableLabs Louisville, CO - USA Email: d.malas@cablelabs.com =20 Hadriel Kaplan Acme Packet Email: hkaplan@acmepacket.com =20 Jason Livingood Comcast Email: Jason_livingood@cable.comcast.com =20 David Schwartz Kayote Systems Email: david.schwartz@kayote.com =20 Rich Shockey Unaffiliated Email: Richard@shockey.us =20 --B_3340703556_372928 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Current -08 Architecture Draft


SPEERMINT Peering Architecture
draft-ietf-speermint-architecture-09

Status= of this Memo
 
   This Internet-Draft is submitted to IETF in full conforma= nce with the
   provisions of BCP 78 and BCP 79.
 
   Internet-Drafts are working documents of the Internet Eng= ineering
   Task Force (IETF), its areas, and its working groups. &nb= sp;Note that
   other groups may also distribute working documents as Int= ernet-
   Drafts.
 
   Internet-Drafts are draft documents valid for a maximum o= f six months
   and may be updated, replaced, or obsoleted by other docum= ents at any
   time.  It is inappropriate to use Internet-Drafts as= reference
   material or to cite them other than as "work in prog= ress."
 
   The list of current Internet-Drafts can be accessed at    http= ://www.ietf.org/ietf/1id-abstracts.txt.
 
   The list of Internet-Draft Shadow Directories can be acce= ssed at
   http://www.ietf= .org/shadow.html.
 
   This Internet-Draft will expire on May 26, 2010.
 
Copyright Notice
 
   Copyright (c) 2009 IETF Trust and the persons identified = as the
   document authors.  All rights reserved.
 
   This document is subject to BCP 78 and the IETF Trust's L= egal Provisions
   Relating to IETF Documents (http://trustee.ietf.org/license-info)
   in effect on the date of publication of this document. Pl= ease
   review these documents carefully, as they describe your r= ights and
   restrictions with respect to this document.  Code Co= mponents
   extracted from this document must include Simplified BSD = License
   text as described in Section 4.e of the Trust Legal Provi= sions and
   are provided without warranty as described in the BSD Lic= ense."     
 
 
Abstract
This document defines the SPEERMINT peering architecture, its functional co= mponents and peering interface functions. It also describes the steps taken = to establish a session between two peering domains in the context of the fun= ctions defined.   
Table of Contents
=
1. Introduction. 2
2. Reference SPEERMINT Architecture. 4
3. Procedures of Inter-domain SSP Session Establishment. 4
3.1. Relationships between functions/elements... 5
4. Recommended SSP Procedures. 5
4.1. Originating SSP Procedures... 5
4.1.1. The Look-Up Function (LUF) 5
4.1.1.1. Target Address Analysis.. 6
4.1.1.2. ENUM Lookup.. 6
4.1.2. Location Routing Function (LRF) 6
4.1.2.1. DNS Resolution.. 7
4.1.2.2. Routing Table.. 7
4.1.2.3. LRF to LRF Routing.. 7
4.1.3. The Signaling Path Border Element (SBE) 7
4.1.3.1. Establishing a Trusted Relationship.. 8
4.1.3.2. Sending the SIP request.. 8
4.2. Target SSP Procedures... 8
4.2.1. The Ingress Signaling Path Border Element (SBE) 8
4.2.1.1. TLS.. 8
4.2.1.2. Receive SIP requests.. 9
4.3. Data Path Border Element (DBE)... 9
5. Address space considerations. 9
6. Security Considerations. 9
7. IANA Considerations. 10
8. Acknowledgments. 10
9. References. 11
9.1. Normative References... 11
9.2. Informative References... 12
Author's Addresses. 13
 
1. Introduction   
The objective of this document is to define a reference peering archite= cture in the context of Session PEERing for Multimedia INTerconnect (SPEERMI= NT). In this process, we define the peering reference architecture, its func= tional components, and peering interface functions from the perspective of a= SIP Service provider’s (SSP) network.  
This architecture allows the interconnection of two SSPs in layer 5 peering= as defined in the SPEERMINT Requirements [14] and Terminology [13] document= s.
Layer 3 peering is outside the scope of this document. Hence, the figures i= n this document do not show routers so that the focus is on Layer 5 protocol= aspects.  
This document uses terminology defined in the SPEERMINT Terminology documen= t [13], so the reader should be familiar with all the terms defined there. In this document, the key words "MUST", "MUST NOT", &qu= ot;REQUIRED",  "SHALL", "SHALL NOT", "SHO= ULD", "SHOULD NOT", "RECOMMENDED", "MAY",= and "OPTIONAL" are to be interpreted as described in [RFC2119].  
2. Reference SPEERMINT Architecture
Figure 2 depicts the SPEERMINT architecture and logical functions that = form the peering between two SSPs.=20


  ---------------         = ;            &nb= sp;   ---------------
  /           &= nbsp;  \          &nb= sp;            /=             &nb= sp;\
 |    +--LUF-+     |   &n= bsp;   +------+       |  &= nbsp;  +--LUF-+    |
 | |->|      |     | &= nbsp;     | ENUM |      &n= bsp;|     |      |<-| |
 | |  |      +------------>| TN DB|&l= t;------------+     |  | |
 | |  |      |     |=       +------+      =  |     |      |  | |<= BR>  | |  +------+     |     =             &nbs= p;   |    +------+  | |
 | |            = ;  |           &= nbsp;          |  &nb= sp;           | |
 | |  +--LRF-+     |     =  +--------+      |     +--= LRF-+  | |
 | |->|     |     |  &= nbsp;   | DNS    |     &nb= sp;|     |      |<-| |
 | |  |      +----------->|IP Addrs|&= lt;-----------+     |  | |
 | |  |      |     |=      +--------+      | &n= bsp;   |      |  | |
 | |  +------+     |     =             &nbs= p;   |    +------+  | |
 | |            = ;  |           &= nbsp;         |   &nb= sp;          | |
 | |            = ;  |           &= nbsp;         |   &nb= sp;          | |
 | |          +-------+ &= nbsp;           +----= ---+           | |
 | ----------->|       |   =           |   &n= bsp;  |<----------- |
 |            |=  SBE  |<------------>|  SBE  |    =         |
 |            |=      |        &= nbsp;    |      |   &= nbsp;        |
 |            += -------+            &= nbsp;+-------+           &= nbsp;|
 |    SSP1        | =             &nbs= p;       |      = SSP2     |
 |            += -------+            &= nbsp;+-------+           &= nbsp;|
 |            |=      |        &= nbsp;    |      |   &= nbsp;        |
 |            |=  DBE  |<------------>|  DBE  |    =          |
 |            |=      |        &= nbsp;    |      |   &= nbsp;        |
 |            += -------+            &= nbsp;+-------+           &= nbsp;|
  \           &= nbsp;  /          &nb= sp;            \=             &nb= sp;/
  ---------------         = ;            &nb= sp;   ---------------
Figure 1: Reference SPEERMINT Architecture


For further details on the elements and functions described in this figure,= please refer to [RFC 5486].
 
3. Procedures of Inter-domain SSP Session Establishment
This document assumes that in order for a session to be established fro= m a UA in the Originating SSP’s network to an UA in the Target SSPR= 17;s network the following steps are taken:  
1.  Determine the target SSP via the LUF.  
a.  If the target address represents an intra-SSP resource, the behavi= or is out-of-scope with respect to this draft.
2.  Determine the address of the SF of the target SSP via the LRF.
3.  Establish the session
4.  Exchange the media, which could include voice, video, tec, etc. 5.  End the session (BYE)
The originating SSP would likely perform steps 1-4, and the target SSP woul= d likely perform steps 4-5.
In the case the target SSP changes, then steps 1-4 would be repeated. This = is reflected in Figure 2 that shows the target SSP with its own peering func= tions.
3.1. Relationships between functions/elements
-  An SBE can contain a SF functio= n.
-  An SF can perform LUF and LRF functions.
-  As an additional consideration, a Session Border Controller [SBC RF= C], can contain an SF, SBE and DBE, and may perform the LUF and LRF function= s.
-  The following functions can communicate as follows, depending upon = various real-world implementations:
o  SF can communicate with LUF, LRF, SBE and SF
o  LUF can communicator with SF and SBE
o  LRF can communicate with SF and SBE
4. Recommended SSP Procedures
This section describes the functions in more detail and provides some r= ecommendations on the role they would play in a SIP call in a Layer 5 peerin= g scenario.
Some of the information in the section is taken from [14] and is put here f= or continuity purposes.
4.1. Originating SSP Procedures
4.1.1. The Look-Up Function (LUF)
Purpose is to determine the SF of the t= arget domain of a given request and optionally develop Session Establishment= Data.
4.1.1.1. Target Address Analysis
When the originating SSP receives a request to communicate, it analyzes= the target URI to determine whether the call needs to be routed internal or= external to its network. The analysis method is internal to the SSP; thus, = outside the scope of SPEERMINT.
If the target address does not represent a resource inside the originating = SSP’s administrative domain or federation of domains, then the origina= ting SSP performs a Lookup Function (LUF) to determine a target address, and= then is resolves the call routing data by using the Location routing Functi= on (LRF).
For example, if the request to communicate is for an im: or pres: URI type,= the originating SSP follows the procedures in [8]. If the highest priority = supported URI scheme is sip: or sips: the originating SSP skips to SIP DNS r= esolution in Section 5.1.3. Likewise, if the target address is already a sip= : or sips: URI in an external domain, the originating SSP skips to SIP DNS r= esolution in Section 4.1.2.1.  
If the target address corresponds to a specific E.164 address, the SSP may = need to perform some form of number plan mapping according to local policy. =  For example, in the United States, a dial string beginning "011 4= 4" could be converted to "+44", or in the United Kingdom &quo= t;00 1" could be converted to "+1".  Once the SSP has an= E.164 address, it can use ENUM.
 
4.1.1.2. ENUM Lookup
If an external E.164 address is the target, the originating SSP consult= s the public "User ENUM" rooted at e164.arpa, according to the pro= cedures described in RFC 3761.  The SSP must query for the "E2U+si= p" enumservice as described in RFC 3764 [11], but MAY check for other e= numservices. The originating SSP MAY consult a cache or alternate representa= tion of the ENUM data rather than actual DNS queries.  Also, the SSP ma= y skip actual DNS queries if the originating SSP is sure that the target add= ress country code is not represented in e164.arpa.  If a sip: or sips: = URI is chosen the SSP skips to Section 5.1.6.
If an im: or pres: URI is chosen for based on an "E2U+im" [8] or = "E2U+pres" [9] enumserver, the SSP follows the procedures for reso= lving these URIs to URIs for specific protocols such a SIP or XMPP as descri= bed in the previous section.
 
4.1.2. Location Routing Function (LRF)
The LRF of an Originating SSP analyzes = target address and target domain identified by the LUF, and discovers the ne= xt hop signaling function (SF) in a peering relationship. The resource to de= termine the SF of the target domain might be provided by a third-party as in= the assisted-peering case.  The following sections define mechanisms w= hich may be used by the LRF. These are not in any particular order and, impo= rtantly, not all of them may be used.
 
4.1.2.1. DNS Resolution
The originating SSP uses the procedures in RFC 3263 [4] Section 4 to de= termine how to contact the receiving SSP.  To summarize the RFC 3263 pr= ocedure: unless these are explicitly encoded in the target URI, a transport = is chosen using NAPTR records, a port is chosen using SRV records, and an ad= dress is chosen using A or AAAA records.
When communicating with another SSP, entities compliant to this document sh= ould select a TLS-protected transport for communication from the originating= SSP to the receiving SSP if available.  
 
4.1.2.2. Routing Table
If there are no End User ENUM records and the Originating SSP cannot di= scover the carrier-of-record or if the Originating SSP cannot reach the carr= ier-of-record via SIP peering, the Originating SSP may deliver the call to t= he PSTN or reject it.  Note that the originating SSP may forward the ca= ll to another SSP for PSTN gateway termination by prior arrangement using th= e routing table.
If so, the originating SSP rewrites the Request-URI to address the gateway = resource in the target SSP's domain and MAY forward the request on to that S= SP using the procedures described in the remainder of these steps.
4.1.2.3. LRF to LRF Routing   
Communications between the LRF of two interconnecting SSPs may use DNS = or statically provisioned IP Addresses for reachability.  Other inputs = to determine the path may be code-based routing, method-based routing, Time = of day, least cost and/or source-based routing.
4.1.3. The Signaling Path Border Element (SBE)=
The purpose of signaling function is to= perform routing of SIP messages as well as optionally implement security an= d policies on SIP messages, and to assist in discovery/exchange of parameter= s to be used by the Media Function (MF).
The signaling function performs the routing of SIP messages. The optional t= ermination and re-initiation of calls may be performed by the signaling path= Session Border Element (SBE), or other signaling elements.  
Optionally, a SF may perform additional functions such as Session Admission= Control, SIP Denial of Service protection, SIP Topology Hiding, SIP header = normalization, SIP security, privacy, and encryption.
The SF of a SBE can also process SDP payloads for media information such as= media type, bandwidth, and type of codec; then, communicate this informatio= n to the media function. Signaling function may optionally communicate with = the network to pass Layer 3 related policies [10]
4.1.3.1. Establishing a Trusted Relationship
Depending on the security needs and trust relationships between SSPs, d= ifferent security mechanism can be used to establish SIP calls. These are di= scussed in the following subsections.
4.1.3.1.1. IPSec
In certain deployments the use of IPSec between the signaling functions= of the originating and terminating domains can be used as a security mechan= ism instead of TLS.
 
4.1.3.1.2. Co-Location  
In this scenario the SFs are co-located in a physically secure location= and/or are members of a segregated network. In this case messages between t= he originating and terminating SSPs would be sent as clear text.
4.1.3.2. Sending the SIP request
Once a trust relationship between the peers is established, the origina= ting SSP sends the request.  
 
4.2. Target SSP Procedures
4.2.1. The Ingress Signaling Path Border Element (SBE)
4.2.1.1. TLS
When the receiving SSP receives a TLS client hello, it responds with it= s certificate.  The Target SSP certificate should be valid and rooted i= n a well-known certificate authority. The procedures to authenticate the SSP= ’s originating domain are specified in [24].
The SF of the Target SSP verifies that the Identity header is valid, corres= ponds to the message, corresponds to the Identity-Info header, and that the = domain in the From header corresponds to one of the domains in the TLS clien= t certificate.
4.2.1.2. Receive SIP requests
Once a trust relationship is established, the Target SSP is prepared to= receive incoming SIP requests.  For new requests (dialog forming or no= t) the receiving SSP verifies if the target (request-URI) is a domain that f= or which it is responsible. For these requests, there should be no remaining= Route header field values. For in-dialog requests, the receiving SSP can ve= rify that it corresponds to the top-most Route header field value.
The receiving SSP may reject incoming requests due to local policy. When a = request is rejected because the originating SSP is not authorized to peer, t= he receiving SSP should respond with a 403 response with the reason phrase &= quot;Unsupported Peer".
4.3. Data Path Border Element (DBE)
The purpose of the DBE [RFC 5486] is to= perform media related functions such as media transcoding and media securit= y implementation between two SSPs.
An Example of this is to transform a voice payload from one codec (e.g., G.= 711) to another (e.g., EvRC). Additionally, the MF may perform media relayin= g, media security, privacy, and encryption.
 
5. Address space considerations

Peering must occur in a common IP address space, which is defined by the fe= deration, which may be entirely on the public Internet, or some private addr= ess space. The origination or termination networks may or may not entirely b= e in the same address space.  If they are not, then a network address t= ranslation (NAT) or similar may be needed before the signaling or media is p= resented correctly to the federation. The only requirement is that all assoc= iated entities across the peering interface are reachable.
 
6. Security Considerations

In all cases, cryptographic-based security should be maintained as an optio= nal requirement between peering providers conditioned on the presence or abs= ence of underlying physical security of SSP connections, e.g. within the sam= e secure physical building.   
In order to maintain a consistent approach, unique and specialized security= requirements common for the majority of peering relationships, should be st= andardized within the IETF.  These standardized methods may enable capa= bilities such as dynamic peering relationships across publicly maintained in= terconnections.
7. IANA Considerations
 There are no IANA considerations at this time.
 
8. Acknowledgments
 The working group thanks Sohel Khan for his initial architecture=
  draft that helped to initiate work on this draft.
 
  A significant portion of this draft is taken from [14] with   permission from the author R. Mahy. The other important contrib= utor
  is Otmar Lendl. Special thanks to Jim McEachern for detailed co= mments and
  feedback.

9. References
9.1. Normative References
[1]      Bradn= er, S., "Key words for use in RFCs to Indicate Requirement Levels"= , BCP 14, RFC 2119, March 1997.
[2]      Mealling, M. and R. Daniel, "The Nam= ing Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September= 2000.
[3]      Rosenberg, J., Schulzrinne, H., Camarillo= , G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, = "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[4]      Rosenberg, J. and H. Schulzrinne, "S= ession Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June= 2002.
[5]      Blake-Wilson, S., Nystrom, M., Hopwood, D= ., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extens= ions", RFC 4366, April 2006.
[6]      Schulzrinne, H., Casner, S., Frederick, R= ., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applicatio= ns", STD 64, RFC 3550, July 2003.
[7]      Peterson, J., Liu, H., Yu, J., and B. Cam= pbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)&= quot;, RFC 3824, June 2004.
[8]      Peterson, J., "Address Resolution fo= r Instant Messaging and Presence",RFC 3861, August 2004.  
[9]      Peterson, J., "Telephone Number Mapp= ing (ENUM) Service Registration for Presence Services", RFC 3953, Janua= ry 2005.
[10]    ETSI TS 102 333: " Telecommunications and Inter= net converged Services and Protocols for Advanced Networking (TISPAN); Gate = control protocol".
[11]    Peterson, J., "enumservice registration for Ses= sion Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 20= 04.
[12]    Livingood, J. and R. Shockey, "IANA Registratio= n for an          Enumservice C= ontaining PSTN Signaling Information", RFC 4769, November 2006.
9.2. Informative References
[13]    Malas, D., "= ;SPEERMINT Terminology", draft-ietf-speermint-terminology-16 (work in p= rogress), February 2008.
[14]    Mule, J-F., "SPEERMINT Requirements for SIP-bas= ed VoIP Interconnection", draft-ietf-speermint-requirements-04.txt, Feb= ruary 2008.
[15]    Mahy, R., "A Minimalist Approach to Direct Peer= ing", draft-        mahy-speermint-d= irect-peering-02.txt, July 2007.
[16]    Penno, R., et al., "SPEERMINT Routing Architect= ure Message          Flows"= ;, draft-ietf-speermint-flows-02.txt", April 2007.
[17]    Houri, A., et al., "RTC Provisioning Requiremen= ts", draft-        houri-speermint-r= tc-provisioning-reqs-00.txt, June, 2006.
[18]    Habler, M., et al., "A Federation based VOIP Pe= ering        Architecture", draft-le= ndl-speermint-federations-03.txt, September 2006.
[19]    Mahy, R., "A Telephone Number Mapping (ENUM) Se= rvice          Registration for= Instant Messaging (IM) Services", draft-ietf-     =    enum-im-service-03 (work in progress), March 2006.
[20]    Haberler, M. and R. Stastny, "Combined User and= Carrier ENUM in the e164.arpa tree", draft-haberler-carrier-enum-03 (w= ork in progress), March 2006.
[21]    Penno, R., Malas D., and Melampy, P., "A Sessio= n Initiation          Protocol = (SIP) Event package for Peering", draft-penno-sipping-peering-package-0= 0 (work in progress), September 2006.
[22]    Hollander, D., Bray, T., and A. Layman, "Namesp= aces in XML", W3C REC REC-xml-names-19990114, January 1999.
[23]    Burger, E (Ed.), "A Mechanism for Content Indir= ection in          Session Init= iation Protocol (SIP) Messages", RFC 4483, May 2006
[24]    Gurbani, V., Lawrence, S., and B. Laboratories, &quo= t;Domain Certificates in the Session Initiation Protocol (SIP)", draft-= ietf-sip-domain-certs-00 <http://potaroo.net/ietf/idref/draft-i= etf-sip-hitchhikers-guide/rfcmarkup?repository=3D/away/ietf&url=3D/away/ietf= /all-ids/draft-ietf-sip-domain-certs-00> (work in progress), November 2007.
Author's Addresses
Adam Uzelac
Global Crossing
Rochester, NY - USA
Email: adam.uzelac@globalcrossing.= com
 
Reinaldo Penno
Juniper Networks
Sunnyvale, CA - USA
Email: rpenno@juniper.net
 
Mike Hammer
Cisco Systems
Herndon, VA - USA
Email: mhammer@cisco.com  
    
Sohel Khan, Ph.D.
Comcast Cable Communications  
USA
Email: sohel_khan@cable.comcast.com<= /a>
    
Daryl Malas
CableLabs
Louisville, CO - USA
Email: d.malas@cablelabs.com <= mailto:d.malas@cablelabs.com>
 
Hadriel Kaplan
Acme Packet
Email: hkaplan@acmepacket.com
 
Jason Livingood
Comcast
Email: Jason_livingood@cable.co= mcast.com
 
David Schwartz
Kayote Systems
Email: david.schwartz@kayote.com  
Rich Shockey
Unaffiliated
Email: Richard@shockey.us
 
 --B_3340703556_372928-- From jason_livingood@cable.comcast.com Mon Nov 9 20:27:42 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0121F3A6927 for ; Mon, 9 Nov 2009 20:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.761 X-Spam-Level: * X-Spam-Status: No, score=1.761 tagged_above=-999 required=5 tests=[AWL=-3.459, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww71h6a-ThoE for ; Mon, 9 Nov 2009 20:27:41 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 56E033A691E for ; Mon, 9 Nov 2009 20:27:37 -0800 (PST) Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.72475692; Mon, 09 Nov 2009 23:27:48 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 23:27:49 -0500 Received: from 133.93.17.128 ([133.93.17.128]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 10 Nov 2009 04:27:48 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 10 Nov 2009 13:27:45 +0900 From: Jason Livingood To: "speermint@ietf.org" Message-ID: Thread-Topic: draft-hancock-sip-interconnect-guidelines-02 URL Thread-Index: AcphviZveV5DOpni9kSMZsGiqR7qig== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340704466_450539" X-OriginalArrivalTime: 10 Nov 2009 04:27:49.0122 (UTC) FILETIME=[28E46E20:01CA61BE] Subject: [Speermint] draft-hancock-sip-interconnect-guidelines-02 URL X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:27:42 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3340704466_450539 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit http://www.ietf.org/id/draft-hancock-sip-interconnect-guidelines-02.txt --B_3340704466_450539 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable draft-hancock-sip-interconnect-guidelines-02 URL http://www.ietf.org/id/draft-hancock-sip-interconnect-guidelines-02.= txt --B_3340704466_450539-- From JMCE@nortel.com Tue Nov 10 00:38:58 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8436128C12F for ; Tue, 10 Nov 2009 00:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqypu6Eqe1uL for ; Tue, 10 Nov 2009 00:38:57 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8F56028C0FB for ; Tue, 10 Nov 2009 00:38:57 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nAA8dJk18921 for ; Tue, 10 Nov 2009 08:39:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA61E1.4AE4EC27" Date: Tue, 10 Nov 2009 03:39:14 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SPEERMINT SIP Interconnect Guidelines and other Standards? Thread-Index: Acph4UeE44Cpo/oFRQuhZ8TXdNys2Q== From: "James McEachern" To: Subject: [Speermint] SPEERMINT SIP Interconnect Guidelines and other Standards? X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 08:38:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA61E1.4AE4EC27 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was wondering if our SIP Interconnect Guidelines is factoring in related activities in other organizations. Specifically I was wondering about: - ITU-T Q.3401 NGN NNI signalling profile (protocol set 1)=20 - ITU-T Q.3401 (2007) Amend. 1 (2008-02) Extensions of NGN NNI signalling profile including video and data services - i3Forum Technical Interconnection Model for International Voice Services=20 - i3Forum IP international interconnections for voice and other related services - GSMA IR.34 Inter-Service Provider IP Backbone Guidelines In addition, ATIS Next Generation Carrier Interconnect is tackling a similar space. Jim McEachern T:+1 613 763-3419 M:+1 613 853-0176 ------_=_NextPart_001_01CA61E1.4AE4EC27 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SPEERMINT SIP Interconnect Guidelines and other = Standards?

I was = wondering if our SIP Interconnect = Guidelines is factoring in related = activities in other organizations.  Specifically I was wondering = about:

-       ITU-T Q.3401 NGN NNI signalling profile (protocol set = 1) 

-       ITU-T Q.3401 (2007) Amend. 1 = (2008-02) Extensions of NGN NNI signalling profile including video = and data services

-       i3Forum Technical Interconnection = Model for International Voice Services

-       i3Forum IP international interconnections for voice and other related = services

-       GSMA IR.34 Inter-Service = Provider IP Backbone Guidelines

In = addition, ATIS Next Generation Carrier Interconnect is tackling a = similar space.

Jim = McEachern

T:+1 613 = 763-3419

M:+1 613 = 853-0176

------_=_NextPart_001_01CA61E1.4AE4EC27-- From D.Malas@cablelabs.com Tue Nov 10 20:26:31 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF573A6930 for ; Tue, 10 Nov 2009 20:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.535 X-Spam-Level: X-Spam-Status: No, score=0.535 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNcyGKtFh+ws for ; Tue, 10 Nov 2009 20:26:30 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 313C03A67EB for ; Tue, 10 Nov 2009 20:26:30 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id nAB4QvC3021628; Tue, 10 Nov 2009 21:26:57 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 10 Nov 2009 21:26:57 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) Received: from 10.253.129.12 ([10.253.129.12]) by srvxchg3.cablelabs.com ([10.5.0.25]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Nov 2009 04:26:57 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 11 Nov 2009 13:26:54 +0900 From: Daryl Malas To: James McEachern , Message-ID: Thread-Topic: [Speermint] SPEERMINT SIP Interconnect Guidelines and other Standards? Thread-Index: Acph4UeE44Cpo/oFRQuhZ8TXdNys2QAperuC In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340790814_7193015" X-Approved: ondar Subject: Re: [Speermint] SPEERMINT SIP Interconnect Guidelines and other Standards? X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:26:31 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3340790814_7193015 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Jim, Thanks. We will do our best to evaluate what other standards bodies have done or are doing related to this work. We certainly welcome feedback from those intimately involved in these other works to read the draft and provide feedback regarding overlap or other comments. Regards, Daryl On 11/10/09 5:39 PM, "James McEachern" wrote: > I was wondering if our SIP Interconnect Guidelines is factoring in related > activities in other organizations. Specifically I was wondering about: > > - ITU-T Q.3401 NGN NNI signalling profile (protocol set 1) > > - ITU-T Q.3401 (2007) Amend. 1 (2008-02) Extensions of NGN NNI > signalling profile including video and data services > > - i3Forum Technical Interconnection Model for International Voice > Services > > - i3Forum IP international interconnections for voice and other related > services > > - GSMA IR.34 Inter-Service Provider IP Backbone Guidelines > > In addition, ATIS Next Generation Carrier Interconnect is tackling a similar > space. > > Jim McEachern > > T:+1 613 763-3419 > > M:+1 613 853-0176 > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint ----------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com --B_3340790814_7193015 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Speermint] SPEERMINT SIP Interconnect Guidelines and other Stan= dards? Jim,

Thanks.  We will do our best to evaluate what other standards bodies h= ave done or are doing related to this work.  We certainly welcome feedb= ack from those intimately involved in these other works to read the draft an= d provide feedback regarding overlap or other comments.

Regards,

Daryl


On 11/10/09 5:39 PM, "James McEachern" <jmce@nortel.com> wrote:

I= was wondering if our SIP Interconnect Guidelines is factoring in = related activities in other organizations.  Specifically I was won= dering about:

-       ITU-T Q.340= 1 NGN NNI signalling profile (protocol set 1)

-       ITU-T = Q.3401 (2007) Amend. 1 (2008-02) Extensions of NGN NNI signalling profile in= cluding video and data services

-       i3Forum Technical Interconnection Model for International Voice Services

-       i3Forum IP international interconnections for voice and other related services

-       GSMA= I= R.34 Inter-Service Provider IP Backbone Guidelines

In addition, ATIS Next Generation Carrier Interco= nnect is tackling a similar space.

Jim McEachern

T:+1 613 763-3419

M:+1 613 853-0176


___________= ____________________________________
Speermint mailing list
Speermint@ietf.org
https://www.ietf.= org/mailman/listinfo/speermint


-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:d.ma= las@cablelabs.com

 --B_3340790814_7193015-- From root@core3.amsl.com Wed Nov 11 00:45:01 2009 Return-Path: X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AA44C3A6A01; Wed, 11 Nov 2009 00:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091111084501.AA44C3A6A01@core3.amsl.com> Date: Wed, 11 Nov 2009 00:45:01 -0800 (PST) Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-09.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Peering Architecture Author(s) : R. Penno, S. Khan Filename : draft-ietf-speermint-architecture-09.txt Pages : 18 Date : 2009-11-11 This document defines the SPEERMINT peering architecture, its functional components and peering interface functions. It also describes the steps taken to establish a session between two peering domains in the context of the functions defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-speermint-architecture-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-11004453.I-D@ietf.org> --NextPart-- From D.Malas@cablelabs.com Thu Nov 12 00:24:42 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA433A681E for ; Thu, 12 Nov 2009 00:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.735 X-Spam-Level: X-Spam-Status: No, score=0.735 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaFXAo5rAGT8 for ; Thu, 12 Nov 2009 00:24:42 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 058903A6A58 for ; Thu, 12 Nov 2009 00:24:41 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id nAC8P9wO003709; Thu, 12 Nov 2009 01:25:09 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 12 Nov 2009 01:25:09 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) Received: from 10.253.129.2 ([10.253.129.2]) by srvxchg3.cablelabs.com ([10.5.0.25]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Nov 2009 08:25:09 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 12 Nov 2009 17:25:07 +0900 From: Daryl Malas To: Message-ID: Thread-Topic: [Speermint] IETF 76 Speermint Meeting Minutes Thread-Index: AcpjcaQnP1Q5IEgQ3E6HIT8tihyH0w== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340891508_9536640" X-Approved: ondar Subject: [Speermint] IETF 76 Speermint Meeting Minutes X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 08:24:42 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3340891508_9536640 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, The minutes for the meeting this week at the 76th IETF have been posted: http://www.ietf.org/proceedings/09nov/minutes/speermint.txt Regards, Daryl ----------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com --B_3340891508_9536640 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable [Speermint] IETF 76 Speermint Meeting Minutes All,

The minutes for the meeting this week at the 76th IETF have been posted:
http:= //www.ietf.org/proceedings/09nov/minutes/speermint.txt

Regards,

Daryl

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:d.ma= las@cablelabs.com

 --B_3340891508_9536640-- From victor.pascual.avila@gmail.com Fri Nov 20 02:30:15 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2E03A6AAD for ; Fri, 20 Nov 2009 02:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHPEVpHTB6SR for ; Fri, 20 Nov 2009 02:30:14 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id F0E1D3A6AA9 for ; Fri, 20 Nov 2009 02:30:13 -0800 (PST) Received: by bwz23 with SMTP id 23so3319617bwz.29 for ; Fri, 20 Nov 2009 02:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DjbqLy6Uv3/T8BbME6FFFI51d/XRMNun2BcIEHiZOKc=; b=JB3Xcc+vUlX2s0jC+UJxoMl3A/qZFZIBaP9aZd+6f9SjbjQiYj8IYWKnKZpxde+VZj eB5+++iA3dVB4CgfY4+28CtZlyBXTIYxRWNSPePXCU5HaePO86tImkhr55wRFOHBY7RN 5BUusNwfxq6GbF83coDT/FkDDS1tTuqmInc4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Cf5v6COtezFIpnEFJk44OD2jcKQ9E9CSTyURkEAdUbVNs9H8XFbXMjECgNQZvmk+N/ SXDn9emX097mAwH0vZ0MXyG50fIFoE0WREjrTL/xuHTyVGUG18434W3SXcFKK3QX6Zxf wMbrVJo20qkWyryLIBsIkTHLUf2WdbGBfYt6w= MIME-Version: 1.0 Received: by 10.204.2.196 with SMTP id 4mr1242223bkk.7.1258713007613; Fri, 20 Nov 2009 02:30:07 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Nov 2009 11:30:07 +0100 Message-ID: <618e24240911200230l783ec78bmdd728d6748233fd0@mail.gmail.com> From: Victor Pascual Avila To: James McEachern Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: speermint@ietf.org Subject: Re: [Speermint] SPEERMINT SIP Interconnect Guidelines and other Standards? X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 10:30:15 -0000 On Tue, Nov 10, 2009 at 9:39 AM, James McEachern wrote: > I was wondering if our SIP Interconnect Guidelines is factoring in relate= d > activities in other organizations.=C2=A0 Specifically I was wondering abo= ut: > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ITU-T Q.3401 NGN NNI signalling pro= file (protocol set 1) > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ITU-T Q.3401 (2007) Amend. 1 (2008-= 02) Extensions of NGN NNI > signalling profile including video and data services > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i3Forum Technical Interconnection M= odel for International Voice > Services > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i3Forum IP international interconne= ctions for voice and other > related services > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GSMA IR.34 Inter-Service Provider I= P Backbone Guidelines > > In addition, ATIS Next Generation Carrier Interconnect is tackling a simi= lar > space. AFAIK, ETSI is also working in this area: - ETSI SR 00008-NGN-R3 (early draft) - ETSI DTR/TISPAN-07043-NGN-R3 (stable draft) Cheers, -Victor > > Jim McEachern > > T:+1 613 763-3419 > > M:+1 613 853-0176 > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint > > --=20 Victor Pascual =C3=81vila