Subject: [martini] SIP-PBX, PBX and IP-PBX

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 May 2010 21:54:45 +0200

Hi,

The requirements talk about SIP-PBXs, GIN talks about PBXs, and VERMOUTH talks about IP-PBXs :)

I think we should try to use common terminology, because I assume we are talking about the same thing in all cases, aren't we?.

Regards,

Christer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 24 May 2010 15:08:26 -0500

Speaking as chair, that would be lovely :D

Spencer

> I think we should try to use common terminology, because I assume we are 
> talking about the same thing in all cases, aren't we?.
>
> Regards,
>
> Christer

---

From: Adam Roach <[email-masked]>
Date: Mon, 24 May 2010 15:33:55 -0500

I'll defer to the terminology used in the WG charter, and change GIN to 
read "SIP-PBX" in the next iteration.

/a

On 5/24/10 3:08 PM, Spencer Dawkins wrote:
>> I think we should try to use common terminology, because I assume we 
>> are talking about the same thing in all cases, aren't we?.
>>
>> Regards,
>>
>> Christer 
>
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 25 May 2010 11:47:41 +0200

I suspect in most cases you should not be using xxx-PBX at all, unless it is a restriction of MARTINI that the attached PBX cannot take traffic from other PBXs in the same network. I would also point out that in using MARTINI, what happens in the rest of the PBX should not necessarily be constrained to be SIP.

ETSI and ECMA agreed on a common terminology that started from the original ISO root definition.

"Corporate telecommunication Network (CN): sets of enterprise premises equipment, owned by or managed on behalf of an enterprise that are located at geographically dispersed locations and are interconnected to provide telecommunication services to a defined group of users belonging to that enterprise

enterprise: unit of economic organization or activity, especially a business organization

Next Generation CN (NGCN): self-contained corporate network designed to take advantage of emerging IP-based communications solutions and that can have its own applications and service provisioning

NOTE 1:	For the purpose of the present document it is a corporate network that provides an IP-based interface to an NGN.

NOTE 2:	TR 102 478 [10] uses NGCN to collectively refer to IP-PBXs.

NGCN site: separate part of an NGCN"

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: Monday, May 24, 2010 9:34 PM
> To: Spencer Dawkins
> Cc: [email-masked]
> Subject: Re: [martini] SIP-PBX, PBX and IP-PBX
> 
> I'll defer to the terminology used in the WG charter, and 
> change GIN to read "SIP-PBX" in the next iteration.
> 
> /a
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 May 2010 10:55:29 -0400

That's ok, we can put this in the definitions section:

SIP-PBX: SIP Provisioned Bulk-user eXternalizer

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of DRAGE, Keith (Keith)
> Sent: Tuesday, May 25, 2010 5:48 AM
> 
> I suspect in most cases you should not be using xxx-PBX at all, unless it
> is a restriction of MARTINI that the attached PBX cannot take traffic from
> other PBXs in the same network. I would also point out that in using
> MARTINI, what happens in the rest of the PBX should not necessarily be
> constrained to be SIP.
> 
> "Corporate telecommunication Network (CN): sets of enterprise premises
> equipment, owned by or managed on behalf of an enterprise that are located
> at geographically dispersed locations and are interconnected to provide
> telecommunication services to a defined group of users belonging to that
> enterprise
> 
> Next Generation CN (NGCN): self-contained corporate network designed to
> take advantage of emerging IP-based communications solutions and that can
> have its own applications and service provisioning
> 
> NOTE 1:	For the purpose of the present document it is a corporate
> network that provides an IP-based interface to an NGN.
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 25 May 2010 17:06:55 +0200

Apart from any other issues, all that tells you is it runs SIP (or something nearly but not quite SIP) and is a separate box. That covers about 10% of what it is and needs to be.

Keith 

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Tuesday, May 25, 2010 3:55 PM
> To: DRAGE, Keith (Keith); Adam Roach; Spencer Dawkins
> Cc: [email-masked]
> Subject: RE: [martini] SIP-PBX, PBX and IP-PBX
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of DRAGE, Keith (Keith)
> > I suspect in most cases you should not be using xxx-PBX at 
> all, unless 
> > it is a restriction of MARTINI that the attached PBX cannot take 
> > traffic from other PBXs in the same network. I would also point out 
> > that in using MARTINI, what happens in the rest of the PBX 
> should not 
> > necessarily be constrained to be SIP.
> > 
> > equipment, owned by or managed on behalf of an enterprise that are 
> > located at geographically dispersed locations and are 
> interconnected 
> > to provide telecommunication services to a defined group of users 
> > belonging to that enterprise
> > 
> > Next Generation CN (NGCN): self-contained corporate network 
> designed 
> > to take advantage of emerging IP-based communications solutions and 
> > that can have its own applications and service provisioning
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 May 2010 13:49:26 -0400

OK... how about SIP-PBX: SIP Proxy or B2bua for eXternal-address-of-records?

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Tuesday, May 25, 2010 11:07 AM
> To: Hadriel Kaplan; Adam Roach; Spencer Dawkins
> Cc: [email-masked]
> Apart from any other issues, all that tells you is it runs SIP (or
> something nearly but not quite SIP) and is a separate box. That covers
> about 10% of what it is and needs to be.
> 
> Keith
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 27 May 2010 19:08:19 +0200

You are missing the point. You are 1) trying to define a term which in many cases is the incorrect term; 2) create a definition that does not encompass an essential characteristic.

1)	What we are working with is not restricted to a single entity. The attached device may be an entire network of PBXs, and the incoming calls could be delivered to, or forwarded to, a large number of devices outside the specific attached physical box. Therefore it is much more appropriate to refer to an attached network, and not to an attached PBX. That, according to the ISO definition, is a corporate network, and to distinguish the IP characteristics, a Next Generation Corporate Network (NGCN) which is the term ECMA, TISPAN and now 3GPP are using.

2)	We need to distinguish traffic concentrators from corporate networks. It is possible to build a box which provides a proxy, but all the end registrations are still between UA and the service providers network. That falls within your definition. However the MARTINI solution is still that the end UAs register with the corporate network, and the corporate network (or its gateway to the outside world) independently registers with the service providers network. Beyond what we are talking about in MARTINI (and assuming service-route is tied into the registration, the the corporate network would provide (or source) the services to its end terminals, whereas in the proxy acting as a concentrator type implementation, these would be a means of access to Centrex type services from the service provider.

regards

Keith

> Sent: Tuesday, May 25, 2010 6:49 PM
> [mailto:[email-masked]] 
> > > > On Behalf Of DRAGE, Keith (Keith)
> > > > traffic from other PBXs in the same network. I would also point 
> > > > out that in using MARTINI, what happens in the rest of the PBX
> > > should not
> > > > ETSI and ECMA agreed on a common terminology that 
> started from the 
> > > > original ISO root definition.
> > > >
> > > > enterprise: unit of economic organization or activity, 
> especially 
> > > > a business organization
> > > >
> > > > to take advantage of emerging IP-based communications solutions 
> > > > and that can have its own applications and service provisioning
> > > >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 May 2010 13:47:47 -0400

> 2)	We need to distinguish traffic concentrators from corporate networks. It is possible to build a box which provides a proxy, but all the end registrations are still between UA and the service pro…

What does the above have to do with Martini???

That can already be done without Martini, using normal REGISTER, Route, 
Service-Route, etc.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 May 2010 20:04:01 +0200

Hi,

Maybe we should simply talk about "behavior of a SIP entity that performs bulk registration", or something like that.

A SIP-PBX (or whatever we want to call it) can then be used as an example.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Thursday, May 27, 2010 8:47 PM
To: DRAGE, Keith (Keith)
Cc: Hadriel Kaplan; [email-masked]
Subject: Re: [martini] SIP-PBX, PBX and IP-PBX

        Thanks,
        Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 28 May 2010 08:53:33 +0200

Yes, we could define a term Bulk Registrant (BR) and give SIP-PBXs and NGCNs as examples.

John 

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 27 May 2010 19:04
> To: Paul Kyzivat; DRAGE, Keith (Keith)
> Cc: [email-masked]; Hadriel Kaplan
> Maybe we should simply talk about "behavior of a SIP entity 
> that performs bulk registration", or something like that.
> 
> From: [email-masked] [[email-masked]] On 
> Behalf Of Paul Kyzivat [[email-masked]]
> > 2)    We need to distinguish traffic concentrators from 
> corporate networks. It is possible to build a box which 
> provides a proxy, but all the end registrations are still 
> between UA and the service providers network. That falls 
> within your definition. However the MARTINI solution is still 
> that the end UAs register with the corporate network, and the 
> corporate network (or its gateway to the outside world) 
> independently registers with the service providers network. 
> Beyond what we are talking about in MARTINI (and assuming 
> service-route is tied into the registration, the the 
> corporate network would provide (or source) the services to 
> its end terminals, whereas in the proxy acting as a 
> concentrator type implementation, these would be a means of 
> access to Centrex type services from the service provider.
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 May 2010 13:52:03 +0200

Hi, 

>Yes, we could define a term Bulk Registrant (BR) and give SIP-PBXs and NGCNs as examples.

Yes. 

And, I also believe that the text should say that, from the SSP perspective, the BR implements a SIP UA role. Because, as far as I know, proxies do not register.

Regards,

Christer

> > Maybe we should simply talk about "behavior of a SIP entity that 
> > performs bulk registration", or something like that.
> > 
> > From: [email-masked] [[email-masked]] 
> On Behalf Of 
> > Paul Kyzivat [[email-masked]]
> > corporate networks. It is possible to build a box which provides a 
> > proxy, but all the end registrations are still between UA and the 
> > service providers network. That falls within your 
> definition. However 
> > the MARTINI solution is still that the end UAs register with the 
> > corporate network, and the corporate network (or its gateway to the 
> > outside world) independently registers with the service providers 
> > network.
> corporate network 
> > would provide (or source) the services to its end 
> terminals, whereas 
> > in the proxy acting as a concentrator type implementation, 
> these would 
> > be a means of access to Centrex type services from the service 
> > provider.
> > 
> > That can already be done without Martini, using normal REGISTER, 
> > Route, Service-Route, etc.
> > 
> >         Thanks,
> >         Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 28 May 2010 14:41:09 +0200

Yes. Even a PBX that acts as a proxy on non-REGISTER inbound and outbound requests would be a UA from the perspective of REGISTER, i.e., the BR would be a UA.

John 

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 28 May 2010 12:52
> To: Elwell, John; Paul Kyzivat; DRAGE, Keith (Keith)
> And, I also believe that the text should say that, from the 
> SSP perspective, the BR implements a SIP UA role. Because, as 
> far as I know, proxies do not register.
> 
> Regards,
> 
> Christer
> 
> 
> provides a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 28 May 2010 14:44:50 +0200

>From the perspective of the REGISTER method, yes. What the gateway functionality on the corporate network side does for other methods is entirely up to it (providing it is conformant with appropriate SIP RFCs).

Keith

> Sent: Friday, May 28, 2010 12:52 PM

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 May 2010 14:57:12 +0200

Hi, 

>>And, I also believe that the text should say that, from the SSP 
>>perspective, the BR implements a SIP UA role. Because, as far as I 
>>know, proxies do not register.
> 
>From the perspective of the REGISTER method, yes. What the 
>gateway functionality on the corporate network side does for 
>other methods is entirely up to it (providing it is 
>conformant with appropriate SIP RFCs).

Correct, and there can for sure be some wording about that when describing different usage examples.

But, other than that I believe that what it does on the "other side" is outside the scope of MARTINI.

Regards,

Christer

> > And, I also believe that the text should say that, from the SSP 
> > perspective, the BR implements a SIP UA role. Because, as far as I 
> > know, proxies do not register.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > > > A SIP-PBX (or whatever we want to call it) can then be 
> used as an 
> > > > example.
> > > > 
> > > > Regards,
> > > > 
> > > > Christer
> > > >