headers
Dan Warren | 2 Oct 2007 10:45

RE: [wg-business] WGLCfordraft-ietf-speermint-terminology-12

All

Some of the points made by John (in his comments 14, 15 and 16) I agree
with but I think it goes further than that.  So rather than making a
proper comment, can I check my understanding of the terms as someone
that has picked the spec up recently and tried to understand it?

There are four terms relating to network types - peer network, service
provider, SIP Service Provider and Internet Telephony Service Provider.
The document states that SSP and ITSP are synonymous, although I might
argue that an ITSP is a subset of an SSP, purely because the 'T' part
suggests a specific service attributable to the UA's within that network
and hence also implies something about the way that service is delivered
(or at least ought to).  SSP is more general and hence could include
applications that do not have the same requirements on QoS and hence do
not require the same DSCP marking, but if you are all happy for these to
be equivalent, I am not going to fuss about the semantics of what is
implied by 'telephony'.

Now I get slightly confused.  A Peer Network sounds like it is a special
case of an SSP - in effect a peered SSP.  Is that correct?  If so I'd
suggest for readability of the document, SSP is defined before Peer
Network, and Peer Network is defined as I describe above.

Similarly, an SSP seems to be a specialised SP, in that not only does it
provide L3 transport of SIP signalling and media packets, but also
includes SIP end points.  Similar to my last point, it would help the
document to define SP before SSP, so that the definition of SSP can be
'An SSP is an SP that also includes UASs and UACs...' and then a Peer
Network can be defined as '...an SSP that has connections to peer SSPs
(Continue reading)

Permalink | Reply | 1 comment |
headers
Elwell, John | 2 Oct 2007 11:24
Picon

RE: [wg-business] WGLCfordraft-ietf-speermint-terminology-12

Dan,

I agree with most of what you say. One point, however, is your proposal:
'An SSP is an SP that also includes UASs and UACs...' (which I guess
comes from text in the existing definition of Peer Network, which I
failed to comment on).

Is it a necessary condition that an SSP include UAs (other than B2BUAs,
perhaps)? I guess it depends what we perceive as the scope of an SSP.
UAs such as PSTN gateways, media servers, etc. might be considered part
of the SSP. But a UA in a user's home that uses the services of an SSP?
That to me is not really part of the SSP.

John

> -----Original Message-----
> From: Dan Warren [mailto:DWarren@...] 
> Sent: 02 October 2007 09:45
> To: Elwell, John; Daryl Malas
> Cc: Malas, Daryl; "Peterson, , dmm" <at> 1-4-5.net; 
> speermint@...; Livingood, Jason
> Subject: RE: [Speermint] [wg-business] 
> WGLCfordraft-ietf-speermint-terminology-12
> 
> All
> 
> Some of the points made by John (in his comments 14, 15 and 
> 16) I agree
> with but I think it goes further than that.  So rather than making a
> proper comment, can I check my understanding of the terms as someone
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Warren | 2 Oct 2007 12:58

RE: [wg-business] WGLCfordraft-ietf-speermint-terminology-12

John

You said...

'Is it a necessary condition that an SSP include UAs (other than B2BUAs,
perhaps)? I guess it depends what we perceive as the scope of an SSP.
UAs such as PSTN gateways, media servers, etc. might be considered part
of the SSP. But a UA in a user's home that uses the services of an SSP?
That to me is not really part of the SSP.'

I agree that under the current terminology and associated definitions it
isn't, but lets consider what the practicalities of implementation are.
Suppose I have a UA on my laptop.  Unless the ISP I am using is handling
the SIP signalling from that UA in a special way compared with other
non-SIP traffic, then the ISP is operating as a SP (as defined in 3.8).
The UA has to be associated with some sort of network where my sessions
are handled, applications are applied and methods are forwarded.  This
has to be in an SSP/ITSP, and if that SSP is attached to other SSPs then
it is also a Peer Network.  I guess the point is, do we conceive of UA's
that are in homes that do not need to have an association with an SSP,
even if it is only short term?  

I have to admit that on reading your mail I figured I had made a
mistake, but then on analysing the text and thinking about it, I think
it is an interesting question.  Maybe the way to consider it is
conversely - what do you classify a 'set of SIP user agent servers
(UASs) [2] and SIP user agent clients (UACs) [2] (customers) that are
controlled by a single administrative domain' but do not peer?  So a
completely self contained and non-peering network...  If an SSP does not
imply UACs and UASs, what is the level of SIP awareness within the SSP
(Continue reading)

Permalink | Reply | 1 comment |
headers
Elwell, John | 2 Oct 2007 14:24
Picon

RE: [wg-business] WGLCfordraft-ietf-speermint-terminology-12

Dan,

It is probably a moot point whether a residential UA is within the SSP
or not. Perhaps if the UA is in possession of credentials for that SSP,
allowing it to register and submit other requests such as INVITE and
MESSAGE, then you might regard it as logically part of that SSP. But I
guess the main point I was trying to make is whether it is a necessary
condition that an SSP include UAs. Consider a transit SSP used in
indirect peering. It can be a transit SSP without possessing a single UA
(gateway, phone, media server or whatever).

John

> -----Original Message-----
> From: Dan Warren [mailto:DWarren@...] 
> Sent: 02 October 2007 11:58
> To: Elwell, John; Daryl Malas
> Cc: Malas, Daryl; "Peterson, , dmm" <at> 1-4-5.net; 
> speermint@...; Livingood, Jason
> Subject: RE: [Speermint] [wg-business] 
> WGLCfordraft-ietf-speermint-terminology-12
> 
> John
> 
> You said...
> 
> 'Is it a necessary condition that an SSP include UAs (other 
> than B2BUAs,
> perhaps)? I guess it depends what we perceive as the scope of an SSP.
> UAs such as PSTN gateways, media servers, etc. might be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Warren | 2 Oct 2007 14:31

RE: [wg-business] WGLCfordraft-ietf-speermint-terminology-12

John

You just successfully (maybe inadvertently?) answered my other question
from my first mail - how to classify the transit network, particularly
the transit where there is SIP awareness.  If that transit network is
also an SSP then that makes life a little easier to understand.

The only question that then remains is whether SSPs for tranist with no
UAs should be categorised separately from SSPs that do have UAs but
don't peer.  But then an SSP with UAs that doesn't peer is not in scope
of the work...

I'll shut up now.  Thanks for the help.

Dan 

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@...] 
> Sent: 02 October 2007 13:24
> To: Dan Warren; Daryl Malas
> Cc: Malas, Daryl; "Peterson, , dmm" <at> 1-4-5.net; 
> speermint@...; Livingood, Jason
> Subject: RE: [Speermint] [wg-business] 
> WGLCfordraft-ietf-speermint-terminology-12
> 
> Dan,
> 
> It is probably a moot point whether a residential UA is 
> within the SSP or not. Perhaps if the UA is in possession of 
> credentials for that SSP, allowing it to register and submit
(Continue reading)

Permalink | Reply | 3 comments |
headers
Uzelac, Adam | 2 Oct 2007 16:25

RE: [wg-business]WGLCfordraft-ietf-speermint-terminology-12

> I'll shut up now.  Thanks for the help.
> 
> Dan 

Oh no - you don't get to run away so quickly!  ;)  I think there's some
"wrongness" going on here.  The transit SSP scenario can and does (in
the real world) contain both UACs and UASs.   The bare minimum would be
UASs I believe.  The transit most certainly is a SSP, as is the
originating and terminating domain.  There may be more than one transit.
Any and all of the SSPs can have UACs and/or UASs.  It's more about the
function that the domain performs or pertains to. 

If a residential UA is registered to a UAS or not really shouldn't
matter.  A residential UA alone with some static SIP-routing would
define the originating domain.  If there's reachability with other UAs
without crossing into another SSP, like sessions in the same building,
neighborhood, business group, etc - these are all within the same domain
and no peering occurs.  Should the look-up function result in the
terminating UA being in the terminating domain (think called party) -
then it's a peer relationship between 2 parties:

SSP(O) <---> SSP(T)

If there's no direct path between the originating domain [SSP(O)] and
the terminating domain [SSP(T)], then employment of an intermediary or
transit domain [SSP(t)] may, and oftentimes does, get used:

SSP(O) <---> SSP(t) <---> SSP(T)

I don't know if that clears things up or not, but it's how I organize
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dan Warren | 2 Oct 2007 16:42

RE: [wg-business]WGLCfordraft-ietf-speermint-terminology-12


> 
> > I'll shut up now.  Thanks for the help.
> > 
> > Dan
> 
> Oh no - you don't get to run away so quickly!  ;)  

Well in that case...

> I think 
> there's some "wrongness" going on here.  The transit SSP 
> scenario can and does (in
> the real world) contain both UACs and UASs.   The bare 
> minimum would be
> UASs I believe.  The transit most certainly is a SSP, as is 
> the originating and terminating domain.  There may be more 
> than one transit.
> Any and all of the SSPs can have UACs and/or UASs.  It's more 
> about the function that the domain performs or pertains to. 
> 
> If a residential UA is registered to a UAS or not really 
> shouldn't matter.  A residential UA alone with some static 
> SIP-routing would define the originating domain.  If there's 
> reachability with other UAs without crossing into another 
> SSP, like sessions in the same building, neighborhood, 
> business group, etc - these are all within the same domain 
> and no peering occurs.  Should the look-up function result in 
> the terminating UA being in the terminating domain (think 
> called party) - then it's a peer relationship between 2 parties:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Elwell, John | 2 Oct 2007 16:56
Picon

RE: [wg-business]WGLCfordraft-ietf-speermint-terminology-12

Adam and others,

As an aside, please can we stop talking about UACs and UASs as if they
are really different entities? We have UAs, which when they send a
request act as UACs and when they receive a request act as UASs. A
stand-along UAC or UAS is highly unlikely to exist. For example, a
stand-alone UAS would be able to receive a call (receive an INVITE
request) but would not be able to initiate clearing a call (sending a
BYE request). Please let's just talk about UAs.

John 

> -----Original Message-----
> From: Uzelac, Adam [mailto:Adam.Uzelac@...] 
> Sent: 02 October 2007 15:25
> To: Dan Warren; Elwell, John; Daryl Malas
> Cc: Malas, Daryl; "Peterson, , dmm" <at> 1-4-5.net; 
> speermint@...; Livingood, Jason
> Subject: RE: [Speermint] 
> [wg-business]WGLCfordraft-ietf-speermint-terminology-12
> 
> > I'll shut up now.  Thanks for the help.
> > 
> > Dan 
> 
> Oh no - you don't get to run away so quickly!  ;)  I think 
> there's some
> "wrongness" going on here.  The transit SSP scenario can and does (in
> the real world) contain both UACs and UASs.   The bare 
> minimum would be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Uzelac, Adam | 2 Oct 2007 17:28

RE: [wg-business]WGLCfordraft-ietf-speermint-terminology-12

Note: I might be contradicting myself here a bit, but be that as it
may....I don't think that we should get into the game of how a SP
becomes a SSP. It's a slippery slope there. (Think DPI as an example)
The basic premise or proposition which underlies being an SSP is that it
is "SIP-aware", not how the SP becomes "SIP-aware".

The nature of the SSP(t) is to enable connectivity between SSP(O) and
SSP(T). It's unrealistic to think we can have a complete mesh between
all SSP(O)s and all SSP(T)s.  Let me go on record as a fan of
http://tools.ietf.org/id/draft-lendl-domain-policy-ddds-02.txt to help
with this.

Please note also that I think that any middlemen - read as SSP(t)s -
that add no value will be disintermediated, sooner or later.
(attribution to Mike Hammer from a thread long ago)

Look back to threads from long ago about 'Basic Peering
Requirements'...It's simply impractical, at this time, to have local
route awareness of all SSP(T)s in the world.  Therefore the value of the
SSP(t) here can be to provide route aggregation.  SSP(O)s will most
likely have multiple upstream SSP(t)s.  Until reachability between all
'O and T' SSPs is realized, the SSP(t) or indirect SIP PATH (do not read
as media path) will be a reality.

-AU

> -----Original Message-----
> From: Dan Warren [mailto:DWarren@...] 
> Sent: Tuesday, October 02, 2007 10:43 AM
> To: Uzelac, Adam; Elwell, John; Daryl Malas
(Continue reading)

Permalink | Reply | 0 comments |
headers
Otmar Lendl | 2 Oct 2007 17:45
Picon
Favicon

Indirect Peering (was: WGLCfordraft-ietf-speermint-terminology-12)


Adam,

excuse me for barging in here:

On 2007/10/02 16:10, "Uzelac, Adam"
<Adam.Uzelac@...> wrote:
> 
> If a residential UA is registered to a UAS or not really shouldn't
> matter.  A residential UA alone with some static SIP-routing would
> define the originating domain.  If there's reachability with other UAs
> without crossing into another SSP, like sessions in the same building,
> neighborhood, business group, etc - these are all within the same domain
> and no peering occurs.  Should the look-up function result in the
> terminating UA being in the terminating domain (think called party) -
> then it's a peer relationship between 2 parties:
> 
> SSP(O) <---> SSP(T)
> 
> If there's no direct path between the originating domain [SSP(O)] and
> the terminating domain [SSP(T)], then employment of an intermediary or
> transit domain [SSP(t)] may, and oftentimes does, get used:
> 
> SSP(O) <---> SSP(t) <---> SSP(T)
> 
> I don't know if that clears things up or not, but it's how I organize
> the world.  ;)
> 

This is my understanding as well. I just want to bring up a terminology
(Continue reading)

Permalink | Reply | 0 comments |

Gmane