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

From: [email-masked]
Date: Tue, 13 Nov 2007 10:15:02 -0500

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, et al.
	Filename	: draft-ietf-speermint-voip-consolidated-usecases-03.txt
	Pages		: 22
	Date		: 2007-11-13
	
This document will capture VoIP use case for SIP Peering.  It is a 
        consolidation of Speermint use cases drafts. This document depicts 
        many common VoIP peering use cases. These use cases are categorized 
        into three types: Direct, Indirect and Assisted. They are not the 
        exhaust set of use cases but the most common use cases deployed in 
        production 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-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-speermint-voip-consolidated-usecases-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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://www1.ietf.org/mailman/listinfo/speermint

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 13 Nov 2007 15:18:23 -0500

I think you guys indicated that you planned a quick -04 update in the
next 1 to 2 weeks to clean up some things in the draft and ensure that
this is in sync with the terminology I-D.  It would be wonderful to see
a -04 turned around in advance of IETF 70.  Then any feedback from IETF
70 can go into a -05 just after or during the week of IETF 70, after
which we can issue a WGLC.

I am copying the WG on this so everyone understands that we need to
press ahead on this I-D rapidly, and that we'll be reviewing in the
great detail at IETF 70.  So please ensure you read the I-D and get
comments to the authors before IETF 70 (preferred) or at IETF 70. 

Thanks
Jason

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, November 13, 2007 10:15 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Speermint] I-D 
> ACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt 
> 
> 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.
> 
> 	Filename	: 
> draft-ietf-speermint-voip-consolidated-usecases-03.txt
> 	Pages		: 22
> 	Date		: 2007-11-13
> 	
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message. 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 	"FILE 
> /internet-drafts/draft-ietf-speermint-voip-consolidated-usecas
> es-03.txt".
> 	
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Nov 2007 10:23:41 +0000

Well, I didn't see an 04. At the risk of repeating known issues, I will
list some immediate concerns with 03, mainly concerning terminology,
which quite frankly needs a lot of attention, not only within this draft
but for alignment between drafts. Until the terminology is sorted out
and I can get a good grasp of what is what, it is difficult to review
the remainder of the draft with any confidence.

1. "Location Server (LS): A server called upon by originating SSP, 
           either Local or Remote, to obtain the Session Establish Data 
           (SED). Often, the input to the server is an E.164 number and
the 
           SED is a SIP URI."
See separate thread discussing meaning of "SED" in the definitions
draft. The use of SED in the consolidated use cases draft is in conflict
with at least one statement in the definitions draft, where it claims
that SED is a lot more than just the SIP URI derived from original
telephone number. I don't have a strong opinion on what SED should mean,
but we must be consistent within and between drafts, since it seems to
be a fundamental concept in SPEERMINT.

2. This meaning of Location Server (LS) is in conflict with the very
similar term Location Service (LS) in RFC 3261. The SIP meaning of LS is
different - it resolves an AoR into one or more contact URIs. Since
SPEERMINT work is very much tied to SIP, it would be unfortunate to use
two terms with the same acronym and very similar expansions. Perhaps we
need to find a different term.

3. "The originating SSP's client may call the 
           Location Function using ENUM Query/Response, SIP
Invite/Redirect, 
           or other method depending on orginating SSP's infrastructure
and 
           methods available for the data being interrogated, with the 
           response format being appropriate to the Query format."
This occurs within the definition of LS. Are Location Function (defined
later in the document) and Location Server the same thing?

4. "Session Border Element (SBE) : A SBE performs signaling sanitation 
           and security tasks in the signaling plane of Session 
           establishment. Common threats may be DOS or intentionally 
           malformed packet/headers.  This device may perform NAT/PAT or

           enable far-end NAT traversal."
We also have a definition Signalling Path Border Element (SBE) in the
definitions draft. Are these meant to be the same thing? They share the
same acronym, but with different expansions and different meanings.

5. Similarly DBE.

6. "User Endpoint (UE): User Endpoint is the client that makes or 
           receives calls. UE can be sip based or non-sip based. For
non-sip 
           based UE, SM acts as a signaling gateway and translates the
non-
           sip signaling to sip signaling before sending to SBE."
Certain other organisations such (e.g., 3GPP, TISPAN) use UE to mean
"User Equipment". I haven't checked whether the definitions are the same
or different, but it might be wise to avoid any conflicts.

7. "Session Manager (SM): A SM is the home registrar of the user 
           endpoint."
In that case, what is the meaning of a-SM in the Assisting SSP Domain in
figure 1, since there are no UEs there (or if there are, they are
irrelevant to the role of the domain as an Assisting SSP Domain?

8. "Figure 1 Generalized Overview"
This is not completely general, because it shows an assisting domain but
not a transit domain.

9. "Indirect, or transit, peering refers to the establishment of either
a 
        signaling and media path or signaling path alone via one (or
more) 
        referral or transit network(s). In this case it is generally
required 
        that a trust relationship is established between the originating

        service provider and the transit network on one side, and the
transit 
        network and the termination network on the other side."
There should also be a trust relationship between transit networks, if
more than one.

10. In 4.1 to 4.5 terms LUF, LF, SF and MF are defined, but it is not
clear how they relate to the terms already defined (e.g., SM, LS, SBE,
SDE) and there is no picture to show how they relate to each other and
to those other terms. In fact the use cases themselves seem to make use
of the terms defined earlier, mostly, so why do we need these additional
terms?

John

> From: Livingood, Jason [mailto:[email-masked]] 
> Sent: 13 November 2007 20:18
> To: [email-masked]; Uzelac, Adam; Lee, Yiu
> Subject: RE: [Speermint] 
> I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
> 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Nov 2007 12:25:56 -0500

Hi John, 

Adam and I are working on 04 and will release very soon. Comments
inline: 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, November 22, 2007 5:24 AM
To: Livingood, Jason; [email-masked]; Uzelac, Adam; Lee, Yiu
Subject: RE: [Speermint]

	[YL]  Agreed that the usecase draft and term draft must keep in
sync. In the content of 
		consolidated-usecase draft, we focus on discussing voip
usecases, so it is true that 			input is often TN and
output is often sip-uri. We didn't limit the input "must be" TN 
		and output must be "sip-uri". Can you explain to us what
exactly the conflict is?

	[YL]	3261 defined Location Service an abstract service. We
define the term Location Server 
		to deliver both LUF and LF. If seems you suggest to
eliminate LS and use LUF
		and LF to replace LS. Am I right?

	[YL]	Thanks for the catch. The term was changed in the
term-draft. We will update ours.

5. Similarly DBE.

	[YL] Same for DBE.

	[YL] Thanks we will update the name to User 

	[YL]	We cleaned this up in 04.

	[YL]	We are working on the term "transit" and "assisting". In
my understanding, I see a
		transit domain is the same as assisting domain because
the transit needs to help to
		route the message (SF). It is kind of assisting, isn't
it?

	[YL]	Agreed

	[YL] We are in the middle of cleaning up all the terms. We hope
to release it very soon.

John

> this is in sync with the terminology I-D.  It would be wonderful to 
> see a -04 turned around in advance of IETF 70.  Then any feedback from

> IETF 70 can go into a -05 just after or during the week of IETF 70, 
> after which we can issue a WGLC.
> 

> > [email-masked] with the word unsubscribe in the body 
> > of the message.
> > You can also visit
> > logging in, type "cd internet-drafts" and then "get 
> > draft-ietf-speermint-voip-consolidated-usecases-03.txt".
> >

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Nov 2007 18:45:49 +0000

Lee,

My further responses in-line.

John 

> From: Lee, Yiu [mailto:[email-masked]] 
> Sent: 23 November 2007 17:26
> To: Elwell, John; Livingood, Jason; [email-masked]; Uzelac, Adam
> Subject: RE: [Speermint] 
[JRE] The conflict is as follows. The use cases draft says the SIP-URI
is the SED. The terminology draft section 3.3 says that SED is a lot
more than just the SIP-URI and gives a whole bulleted list of things it
includes.

> 		and LF to replace LS. Am I right?
[JRE] No, I am saying we shouldn't use the term Location Server (LS) to
mean something different from the Location Service (LS) that is defined
in RFC 3261, because it appears they mean quite different things. We
should choose a different term. I don't know whether Location Function
would do, because I didn't really understand the difference between LS
and LF - see my next point.

> later in the document) and Location Server the same thing?
[JRE] I am asking whether these two terms are intended to be the same
thing. If they are different things, then the definition of Location
Function should be moved up to the terminology section. But then I am
not sure I appreciate the difference between the two.
By the way, shouldn't some of the terms in the terminology section be in
the terminology draft instead?

> 		route the message (SF). It is kind of assisting, isn't
[JRE] Well, if that is the case we effectively have only two scenarios -
direct and indirect/assisted. But I thought earlier discussions had
identified two orthogonal concepts - assisted and direct/indirect, and
that assisted peering (where the assisting domain does not remain on the
call path) can be used in conjunction with direct peering or with
indirect peering. If you want to collapse it, WG discussion is required.

> > >         consolidation of Speermint use cases drafts. This 
> document 
> > > depicts
> > >         production today. This document captures them to 
> provide a 
> > > reference.
> > > 
> message to

---

From: "James McEachern" <[email-masked]>
Date: Mon, 26 Nov 2007 08:34:01 -0500

Some additional comments inline...

Jim McEachern

-----Original Message-----
From: Lee, Yiu [mailto:[email-masked]] 
Sent: Friday, November 23, 2007 12:26 PM
To: Elwell, John; Livingood, Jason; [email-masked]; Uzelac, Adam
Subject: RE: [Speermint]

Hi John, 

---- snip ----

1. "Location Server (LS): A server called upon by originating SSP,
either Local or Remote, to obtain the Session Establish Data (SED).
Often, the input to the server is an E.164 number and the SED is a SIP
URI."

[YL]  Agreed that the usecase draft and term draft must keep in sync. In
the content of consolidated-usecase draft, we focus on discussing voip
usecases, so it is true that input is often TN and output is often
sip-uri. We didn't limit the input "must be" TN and output must be
"sip-uri". Can you explain to us what exactly the conflict is?

[jmce] Having spent the weekend going over these drafts, I can explain
the conflict.  This definition says "the SED is a SIP URI".  However in
the definitions draft says "...the SED is the set of parameters that the
outgoing SBEs need to complete the call, and may include ... Port ...
Transport Protocol ..."  The definition in the Terminology draft
continues to list several other parameters that clearly show the SED my
begin with the SIP URI, but is not just the SIP URI (which is what this
seems to say).  If you look at the description of the Location Function
in the Architecture Draft, it also indicates that the SED is more than
the SIP URI.  Specifically it says "Purpose is to develop ... SED by
discovering the ... SF and the end user's reachable host (IP address and
port)."  I'd suggest that you consider using the text from the
Architecture draft.

--- snip ---- 

[jmce] I note that the term Session Manager (SM) is used in this draft
and in the Architecture draft, yet is not defined in the Terminology
draft (or anywhere else that I can find, for that matter).  Would it be
appropriate to add this definition to the Terminology draft?

---

From: "Rodrig, Benny (Benny)" <[email-masked]>
Date: Mon, 26 Nov 2007 11:13:26 -0500

Lee, 

>> 		transit domain is the same as assisting domain because
the transit 
>> needs to help to
it?
> direct and indirect/assisted. But I thought earlier discussions had
identified 
> two orthogonal concepts - assisted and direct/indirect, and that
assisted peering
> (where the assisting domain does not remain on the call path) can be
used in
> conjunction with direct peering or with indirect peering. If you want
to collapse
> it, WG discussion is required.

As John said, previous discussions seemed to conclude that Assisted was
orthogonal to direct/indirect, i.e. that Assisting is about the steps
preceding the SIP session routing (i.e. about steps 2 & 3 in Figure 4)
whereas direct vs. indirect/transit is about SIP session routing (i.e.
step 4 in Figure 2 as well as step 5 in Figure 4 for direct, vs. step 5
in Figure 3 for indirect/transit. According to that view:
- Figure 4 is fine
- the text in 5.2 should be modified to not refer to A-SSP SBE handling
the sessions. 
- step 8 in 5.2.1 should be changed from '...through O/A/T DBE' to
'...through O/T DBE'.
- section 5.2.2 is really about indirect/transit and not about Assisted
- the indirect section 5.1.2 needs work. Steps 2 & 3 which determine the
t-SBE can probably be done either in the Orig Domain or via an Assisting
Domain. And then between step 4 and step 5 isn't there a missing step
between t-SBE and t-LS to determine the T-SBE?

Another point is On-demand which is probably also orthogonal to
direct/indirect. The way On-demand was added to section 5.1 there is now
no direct peering case which is not on-demand. Also there is
inconsistency between 5.1.1 which states there is NOT a pre-established
relationship between the domains and 5.1.1.1 which says the opposite. 

Benny