Subject: [martini] Requirements

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jan 2010 17:23:36 +0100

It has been pointed out to me that the materials for today's meeting are rather lacking in requirements. Coming up with a complete set of requirements at short notice is not easy, but a few of the requirements would be along the following lines. Perhaps others could help me refine these on the list, so we have a basis for requirements discussion today.

- The mechanism MUST allow the PBX to be responsible for its AORs and to handle requests to those AORs according to its rules.
- The mechanism MUST allow the PBX to receive requests to its AORs that originate off-PBX and arrive via the SSP, so that the PBX can handle those requests according to its rules.
- The mechanism MUST provide a means whereby the PBX knows which of its AORs an inbound request is targeted at.- The mechanism MUST provide a means of avoiding problems due to one side using the mechanism when the other side does not support it or is not using it.
- The mechanism MUST work in the presence of intermediate "proxies" between the PBX and the SSP's domain proxy, where those intermediate "proxies" need to be on the path of inbound requests to the PBX.
- The mechanism MUST work when the PBX obtains its IP address dynamically.
- The mechanism MUST work without requiring the PBX to publish reachability information through the DNS.

Also some desiderata:
- The mechanism SHOULD allow SSPs to exploit its mechanisms for providing SIP service to ordinary subscribers in order to provide a SIP trunking service to PBXs.
- The mechanism SHOULD scale to PBXs of several thousand users.
- The mechanism SHOULD require relatively modest changes to a substantial population of existing SSP and PBX implementations, in order to encourage a fast market adoption of the standardized mechanism.

John

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 7 Jan 2010 18:03:33 +0100

Most of these I'm happy with.

> - The mechanism SHOULD scale to PBXs of several thousand users.

In my belief the number of users is irrelevant, what we are talking about is distinct URIs.

Can I also use:

> - The mechanism SHOULD require relatively modest changes to a 
> substantial population of existing SSP and PBX 
> implementations, in order to encourage a fast market adoption 
> of the standardized mechanism.

to remind all of you that implicit registration is generic to all IMS users. It is not something that has been crafted especially for PBX attachment, rather the implicit registration is the same as it has always been. The only change is to allow the implicit registration set to contain this concept called "wildcarded public user identities". Even that does not need to be specific to PBX attachment as it is merely a means of providing a shorthand for describing a set of URIs using a single string.

The real IMS change specifically there for PBX usage comes in the effect of the location server / inbound proxy not replacing the request URI when it finds a registered contact.

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Thursday, January 07, 2010 4:24 PM
> To: [email-masked]
> Subject: [martini] Requirements
> 
> It has been pointed out to me that the materials for today's 
> meeting are rather lacking in requirements. Coming up with a 
> complete set of requirements at short notice is not easy, but 
> a few of the requirements would be along the following lines. 
> Perhaps others could help me refine these on the list, so we 
> have a basis for requirements discussion today.
> 
> - The mechanism MUST allow the PBX to be responsible for its 
> AORs and to handle requests to those AORs according to its rules.
> - The mechanism MUST allow the PBX to receive requests to its 
> AORs that originate off-PBX and arrive via the SSP, so that 
> the PBX can handle those requests according to its rules.
> - The mechanism MUST provide a means whereby the PBX knows 
> which of its AORs an inbound request is targeted at.- The 
> mechanism MUST provide a means of avoiding problems due to 
> one side using the mechanism when the other side does not 
> support it or is not using it.
> - The mechanism MUST work in the presence of intermediate 
> "proxies" between the PBX and the SSP's domain proxy, where 
> those intermediate "proxies" need to be on the path of 
> inbound requests to the PBX.
> - The mechanism MUST work without requiring the PBX to 
> publish reachability information through the DNS.
> 
> Also some desiderata:
> - The mechanism SHOULD allow SSPs to exploit its mechanisms 
> for providing SIP service to ordinary subscribers in order to 
> provide a SIP trunking service to PBXs.
> - The mechanism SHOULD require relatively modest changes to a 
> substantial population of existing SSP and PBX 
> implementations, in order to encourage a fast market adoption 
> of the standardized mechanism.
> 
> John
> 
> 
> 
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Jan 2010 11:13:40 -0600

> The real IMS change specifically there for PBX usage comes in the effect of the location server / inbound proxy not replacing the request URI when it finds a registered contact.

But we're not talking about IMS here. Implicit registration in IMS solves a very specific IMS problem that is semantically different than this problem.

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 11:13:58 -0600

This seems like a reasonable set of requirements, although I think our 
idea of "modest changes" may be subtly different. As Ben points out: 
"[based on experience], implementors will be no more willing to make 
small changes than to make bigger ones. Touching anything is the 
expensive part, everything else is just work."

I think it goes as unwritten that we conform to SIP's model of backwards 
compatibility, so we don't really need to add that to the list. But we 
do need to keep it in mind.

And it actually goes as written that we conform to the SIP Change 
process. For example:

    "While interoperability implications can be addressed by
    capabilities negotiation rules, the effects of adding features
    that... deal with a point solution and are not general, are much
    harder to control with rules. Therefore, the RAI Area calls for
    architectural guardianship and application of Occam's Razor by the
    SIPCORE and DISPATCH Working Groups."

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 11:16:39 -0600

On 1/7/10 11:03, Jan 7, DRAGE, Keith (Keith) wrote:
> to remind all of you that implicit registration is generic to all IMS 
> users. It is not something that has been crafted especially for PBX 
> attachment, rather the implicit registration is the same as it has 
> always been.

IMS implicit registration deals with a single server, not a batch of 
disparate users. It's a different operation than is being proposed in 
the shaken draft.

> The only change is to allow the implicit registration set to contain 
> this concept called "wildcarded public user identities".

No. The key change is modifying the semantics to talk about multiple 
users instead of a single user.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 11:18:13 -0600

> disparate users. It's a different operation than is being proposed in 

That should have said "single user," not "single server." Sorry.

/a

---

From: "Brian Lindsay" <[email-masked]>
Date: Thu, 7 Jan 2010 12:54:56 -0500

Hi,

  I don't think it's really fundamentally different in the context of
how 3GPP/TISPAN support SIP PBXs in what they term "subscrption mode".

  3GPP/IMS support for SIP PBXs was driven by work originally done by
TISPAN. TISPAN has the concept of a "Next Generation Corporate Network
(NGCN) Site Identifier", which is basically an AoR representing the SIP
PBX, and which is the used in the registration request from the SIP PBX
to the network. It's basically analagous to the explicit registration
AoR in the Martini-shaken draft. Like in Martini-shaken, TISPAN/3GPP use
implicit registration for the set of AoRs associated with the SIP PBX
users, and for requests routed to the SIP PBX, the request uri is not
overwritten with the registration contact.

  I believe the big difference in Martini-shaken is some of the new
proposed option tags and header fields being added.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Roach
Sent: Thursday, January 07, 2010 12:18 PM
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [martini] Requirements

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 7 Jan 2010 19:44:50 +0100

And you are arguing for a concept of "user" within the SSP which I say is redundant. 

I repeat again, the SSP needs to know about its relationship with the PBX operator, not the set of users that may be hosted on the PBX - that is the responsibility of the PBX operator.

Keith

> From: Adam Roach [mailto:[email-masked]] 
> Sent: Thursday, January 07, 2010 5:17 PM
> To: DRAGE, Keith (Keith)
> Cc: Elwell, John; [email-masked]
> IMS implicit registration deals with a single server, not a 
> batch of disparate users. It's a different operation than is 
> being proposed in the shaken draft.
> 
> No. The key change is modifying the semantics to talk about 
> multiple users instead of a single user.
> 
> /a
>