Subject: [Speermint] I-D Action:draft-ietf-speermint-voip-consolidated-usecases-07.txt

From: [email-masked]
Date: Thu, 8 May 2008 17:00:01 -0700 (PDT)

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           : VoIP SIP Peering Use Cases
	Author(s)       : A. Uzelac, Y. Lee
	Filename        : draft-ietf-speermint-voip-consolidated-usecases-07.txt
	Pages           : 26
	Date            : 2008-05-08

This document depicts many common VoIP use case for SIP Peering.
These use cases are categorized into static and on-demand, and then
further sub-categorized into direct and indirect.  These use cases
are not an exhaustive set, but rather the most common use cases
deployed today.  This document captures them to provide a reference.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-07.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.
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 09 May 2008 16:17:43 -0700

Hello,

Now that we have newer version or architecture and use cases we need to look
at the direction and goals of the flows draft. Before actually talking about
what tasks could be done it would be good to hear from the list what are
their opinions on the draft. A few thoughts:

1 - Many of the flows are present on the use-cases draft. They are not in
"timeline" graphic format but there are messages, players, etc

2 - Many of the flows in the draft are already covered in other SIP drafts,
except for B2BUA/SBC flows.

3 - Given what I said above, it would be good to hear opinions if the draft
should be pursued further and in which format. One format could be to get
the use-cases examples and put them in timeline graphic format using SIP
nomenclature and/or speermint nomenclature. There are other possibilities.

4 - If people think we should pursue this further I would like to ask for
volunteers to help me edit the draft.

Let me know

Thanks,

Reinaldo

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 12 May 2008 13:02:54 -0400

The intent of the last call is to solicit comments before submitting the
ID to the IESG.

The purpose of a working group Last Call is in the style of "speak now
or forever hold your peace" in case there are fundamental objections
which have not gotten previous or adequate discussion, or minor errors
which need correction.

Work group last call will extend for 2 weeks from today, 12 May 2008,
until 26 May 2008.

Please post any comments in reply to the list, as well as to the
editor(s) of this draft.

Regards,

Jason 

> This draft is a work item of the Session PEERing for 
> Multimedia INTerconnect Working Group of the IETF.
> 
> 
> 	Filename        : 
> draft-ietf-speermint-voip-consolidated-usecases-07.txt
> 	Pages           : 26
> 	Date            : 2008-05-08
> 
> These use cases are categorized into static and on-demand, 
> and then further sub-categorized into direct and indirect.  
> These use cases are not an exhaustive set, but rather the 
> most common use cases deployed today.  This document captures 
> them to provide a reference.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 May 2008 22:15:44 -0400

Howdy,
Regarding the latest draft, I have the following comments:

1) I think there is confusion around LUF vs. LRF, or at least I'm confused.  Per the terminology draft, I was under the impression that LUF is the function/step for determining the terminating/owner domain.  So for example, take two providers a.com and b.com.  If a request is created by a user at a.com with a request-uri of tel:+12128675309 or sip:[email-masked];user=phone, a.com would perform an LUF to figure out it belongs to b.com.  If the req-uri already had something like sip:[email-masked], no LUF is needed, because "b.com" is already identified.  The LRF function is to figure out how to actually get to b.com.

In this draft, however, section 5.1.1 starts with the request-uri already being the terminating domain ("example.net" is b.com in the example, and "example.com" is a.com).  It then performs LUF, which is incorrect I believe.  Furthermore, it performs the LUF by querying 3.3.3.3.2.2.2.7.1.9.example.net, which is even less realistic since the example diagram is not showing any sort of cross-DNS concept for this. (note that domain name has "example.net" at the end)  The entire reason LUF is necessary and important, imho, is because a user in a.com rarely knows the call needs to ultimately go to b.com.

Also, the example shows steps 3 and 4 being performed by the O-Proxy, while step 6 is done by the SBE.  That's certainly possible, but I think that's the exception case today, and normally the O-Proxy just does step 2 and the SBE does 3, 4, and 6.

There are also some editorial errors in that example, such as showing a SIPS ENUM service rather than SIP, and a double-backslash for the regex replacement instead of single-backslash, and step 10's contact hostname is wrong. (some of these errors also appear in section 5.1.3.1)

2) Section 5.1.3.1 describes the static indirect peering use case as one where the originating and terminating SSP's "negotiate and agree to establish a SIP peering relation", but still go through an intermediate SSP.  That is rare, afaik.  If the originating and terminating go to the trouble of forming a pre-arranged relationship, they almost always peer direct - the use case for indirect is really that they DON'T have a pre-arranged peering relationship, and the intermediate SSP is in fact there *because* they don't have and reasonably couldn't have a direct one.  I'm not saying that's always the case, but certainly it's the dominant case compared to having a relationship but using an intermediate SSP anyway for other reasons.

-hadriel

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 14 May 2008 16:39:22 -0400

Hadriel,

Thank you very much for taking the time out of your busy schedule to
comb through this doc.  We _really_ appreciate it. 
Regarding your comments:

Point 1) Definition of the LUF from the Term draft...
4.3.1. Look-Up Function - "The Look-Up Function (LUF) provides a
mechanism for determining for a given request the target domain to which
the request should be routed. "   This definition is consistent with
your observations, and we will address the inconsistencies in the next
release of the draft.  With regards to the steps being performed by the
O-proxy versus the SBE, once again, I agree, and will change to reflect
the more commonly deployed scenario.  We will also caveat the fact that
the steps can be done by both or either element.  NITS noted as well.

Point 2) Pertaining to your point about the rarity of the Static
Indirect Use Case model - the use case being described here has in mind
the following...an Enterprise (say 111 bank) has an exclusive
interconnection with a SSP (SSP-A).  111 bank wants to establish
communications with 222 bank.  111 will tell 222 that in order to
communicate with it, it needs to use SSP-A.  In this scenario, all calls
from 111 to 222 with follow the 111 <-> SSP-A <-> 222 indirect path.  I
believe this is more common that you assume.  

Thoughts?

Adam

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Monday, May 12, 2008 10:16 PM
> To: Uzelac, Adam; [email-masked]
> Cc: [email-masked]
> Subject: RE: WGLC:draft-ietf-speermint-voip-consolidated-usecases-07
> 
> Howdy,
> 1) I think there is confusion around LUF vs. LRF, or at least 
> I'm confused.  Per the terminology draft, I was under the 
> impression that LUF is the function/step for determining the 
> terminating/owner domain.  So for example, take two providers 
> a.com and b.com.  If a request is created by a user at a.com 
> with a request-uri of tel:+12128675309 or 
> sip:[email-masked];user=phone, a.com would perform an LUF 
> to figure out it belongs to b.com.  If the req-uri already 
> had something like sip:[email-masked], no LUF is needed, 
> because "b.com" is already identified.  The LRF function is 
> to figure out how to actually get to b.com.
> 
> In this draft, however, section 5.1.1 starts with the 
> request-uri already being the terminating domain 
> ("example.net" is b.com in the example, and "example.com" is 
> a.com).  It then performs LUF, which is incorrect I believe.  
> Furthermore, it performs the LUF by querying 
> 3.3.3.3.2.2.2.7.1.9.example.net, which is even less realistic 
> since the example diagram is not showing any sort of 
> cross-DNS concept for this. (note that domain name has 
> "example.net" at the end)  The entire reason LUF is necessary 
> and important, imho, is because a user in a.com rarely knows 
> the call needs to ultimately go to b.com.
> 
> Also, the example shows steps 3 and 4 being performed by the 
> O-Proxy, while step 6 is done by the SBE.  That's certainly 
> possible, but I think that's the exception case today, and 
> normally the O-Proxy just does step 2 and the SBE does 3, 4, and 6.
> 
> There are also some editorial errors in that example, such as 
> showing a SIPS ENUM service rather than SIP, and a 
> double-backslash for the regex replacement instead of 
> single-backslash, and step 10's contact hostname is wrong. 
> (some of these errors also appear in section 5.1.3.1)
> 
> 2) Section 5.1.3.1 describes the static indirect peering use 
> case as one where the originating and terminating SSP's 
> "negotiate and agree to establish a SIP peering relation", 
> but still go through an intermediate SSP.  That is rare, 
> afaik.  If the originating and terminating go to the trouble 
> of forming a pre-arranged relationship, they almost always 
> peer direct - the use case for indirect is really that they 
> DON'T have a pre-arranged peering relationship, and the 
> intermediate SSP is in fact there *because* they don't have 
> and reasonably couldn't have a direct one.  I'm not saying 
> that's always the case, but certainly it's the dominant case 
> compared to having a relationship but using an intermediate 
> SSP anyway for other reasons.
> 
> -hadriel
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 14 May 2008 22:45:40 -0400

On point 1, perhaps you all can exchange and agree to text for -08 for
this.  Then we can log it as a closed item and not have to repeat WGLC
on -08.

Thanks
Jason 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Uzelac, Adam
> Sent: Wednesday, May 14, 2008 4:39 PM
> To: Hadriel Kaplan; Lee, Yiu
> Cc: [email-masked]
> Subject: Re: 
> [Speermint]WGLC:draft-ietf-speermint-voip-consolidated-usecases-07
> 
> Hadriel,
> 
> Thank you very much for taking the time out of your busy 
> schedule to comb through this doc.  We _really_ appreciate it. 
> Regarding your comments:
> 
> 4.3.1. Look-Up Function - "The Look-Up Function (LUF) 
> provides a mechanism for determining for a given request the 
> target domain to which
> your observations, and we will address the inconsistencies in 
> the next release of the draft.  With regards to the steps 
> being performed by the O-proxy versus the SBE, once again, I 
> agree, and will change to reflect the more commonly deployed 
> scenario.  We will also caveat the fact that the steps can be 
> done by both or either element.  NITS noted as well.
> 
> Point 2) Pertaining to your point about the rarity of the 
> Static Indirect Use Case model - the use case being described 
> here has in mind the following...an Enterprise (say 111 bank) 
> has an exclusive interconnection with a SSP (SSP-A).  111 
> bank wants to establish communications with 222 bank.  111 
> will tell 222 that in order to communicate with it, it needs 
> to use SSP-A.  In this scenario, all calls from 111 to 222 
> with follow the 111 <-> SSP-A <-> 222 indirect path.  I 
> > 1) I think there is confusion around LUF vs. LRF, or at least I'm 
> > confused.  Per the terminology draft, I was under the 
> impression that 
> > LUF is the function/step for determining the 
> terminating/owner domain.  
> > So for example, take two providers a.com and b.com.  If a 
> request is 
> > created by a user at a.com with a request-uri of 
> tel:+12128675309 or 
> > sip:[email-masked];user=phone, a.com would perform an LUF to 
> > figure out it belongs to b.com.  If the req-uri already had 
> something 
> > like sip:[email-masked], no LUF is needed, because "b.com" is 
> > already identified.  The LRF function is to figure out how 
> to actually 
> > get to b.com.
> > 
> > In this draft, however, section 5.1.1 starts with the request-uri 
> > already being the terminating domain ("example.net" is b.com in the 
> > example, and "example.com" is a.com).  It then performs 
> LUF, which is 
> > incorrect I believe.
> > 3.3.3.3.2.2.2.7.1.9.example.net, which is even less realistic since 
> > the example diagram is not showing any sort of cross-DNS 
> concept for 
> > this. (note that domain name has "example.net" at the end)  
> The entire 
> > reason LUF is necessary and important, imho, is because a user in 
> > a.com rarely knows the call needs to ultimately go to b.com.
> > 
> > Also, the example shows steps 3 and 4 being performed by 
> the O-Proxy, 
> > while step 6 is done by the SBE.  That's certainly possible, but I 
> > think that's the exception case today, and normally the 
> O-Proxy just 
> > does step 2 and the SBE does 3, 4, and 6.
> > 
> > There are also some editorial errors in that example, such 
> as showing 
> > a SIPS ENUM service rather than SIP, and a double-backslash for the 
> > regex replacement instead of single-backslash, and step 
> 10's contact 
> > hostname is wrong.
> > 2) Section 5.1.3.1 describes the static indirect peering 
> use case as 
> > one where the originating and terminating SSP's "negotiate 
> and agree 
> > to establish a SIP peering relation", but still go through an 
> > intermediate SSP.  That is rare, afaik.  If the originating and 
> > terminating go to the trouble of forming a pre-arranged 
> relationship, 
> > they almost always peer direct - the use case for indirect 
> is really 
> > that they DON'T have a pre-arranged peering relationship, and the 
> > intermediate SSP is in fact there *because* they don't have and 
> > reasonably couldn't have a direct one.  I'm not saying 
> that's always 
> > the case, but certainly it's the dominant case compared to having a 
> > relationship but using an intermediate SSP anyway for other reasons.
> > 
> > -hadriel
> >

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 15 May 2008 22:42:56 -0400

I am on the road for a business trip. As soon as I get back, I will schedule a time to talk to Adam and Hedriel to agree on the text.
 
Yiu

________________________________

From: Livingood, Jason
Sent: Wed 5/14/2008 10:45 PM
To: Uzelac, Adam; Hadriel Kaplan; Lee, Yiu
Cc: [email-masked]
Subject: RE: [Speermint]WGLC:draft-ietf-speermint-voip-consolidated-usecases-07

On point 1, perhaps you all can exchange and agree to text for -08 for this.  Then we can log it as a closed item and not have to repeat WGLC on -08.

Thanks
Jason

---

From: David Schwartz <[email-masked]>
Date: Mon, 26 May 2008 15:56:05 +0300

In section 5.1.2.1 (page 12) it says: "L5 policy is maintained in the  
O-SSP and T-SSP dpmains and LUF/LRF provider is neither unaware nor  
responsible for L5 policy." Since I assume you mean "is neither aware"  
and not "unaware" I am not sure I agree. I would change the text to  
"may not" as there may be cases where some policy is involved in the  
decision making process of both whether to return a positive response  
as well as the actual ingress point to T.

6.1.3 This is and example of Indirect Peering - I would add coupled  
with Assisted LUF/LRF.

Cheers,

David

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 27 May 2008 16:40:05 -0600

We would like to thank every who provide feedback during this WGLC
period.  The working group last call for this draft has concluded.

Draft editor(s), please close out any remaining issues and update the
draft as necessary.  Please complete this as soon as possible, as this
will allow us to move this draft forward to the next step.  

Thank you,

Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Livingood, Jason
Sent: Monday, May 12, 2008 11:03 AM
To: [email-masked]
Subject: [Speermint]
WGLC:draft-ietf-speermint-voip-consolidated-usecases-07

Regards,

Jason 

> further sub-categorized into direct and indirect.
> These use cases are not an exhaustive set, but rather the most common 
> use cases deployed today.  This document captures them to provide a 
> reference.
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 29 May 2008 09:28:09 -0400

We had a call to resolve the open issues listed in the mailing list. A
new version will be released very soon.

Yiu 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Daryl Malas
Sent: Tuesday, May 27, 2008 6:40 PM
To: [email-masked]
Cc: Livingood, Jason
Subject: Re: [Speermint]
WGLCCompleted:draft-ietf-speermint-voip-consolidated-usecases-07

Thank you,

Daryl

-----Original Message-----

Regards,

Jason