Subject: RE: [IPTEL] iptel-gwreg-req open issues

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Mon, 3 Dec 2001 21:09:29 -0500

Hi, Jon:

It is a good start for discussion via emails as all of us may not
participate in the IETF-52 Salt Lake meeting. I appreciate your thoughtful
comments.

In fact, I am delighted to see that we are almost in full agreement.

My comments are inline [RRR].

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Friday, November 30, 2001 3:15 PM
To: [email-masked]'
Subject: [IPTEL] iptel-gwreg-req open issues

A few comments on the open issues listed in the draft.

REQ 6- I think this is a real requirement. I think that in many complex
architectures (such as ones in which MGCs are used as gateways), the
provisioning of ranges of POTS numbers associated with gateways must be
performed in multiple locations (proxy servers and gateways, at least) if
there is not some sort of gwreg mechanism that allows you to provision in
one place and then automatically propagate the data to any other systems
that need it. In my opinion, simplifying provisioning is one of the primary
reasons to use gateway registration. If you have to substantially
pre-provision proxies then I don't think gateway registration makes your
life that much easier.
...

[RRR] Yes, I agree with you because it is the intra-ITAD environment where a
single carrier/service provider wants to AUTO-provision (not
pre-provisioned) in order to avoid error-prone and costly manual
configurations. This requires communications between the GWs and the LSs
and, registration is one of the important items. A GW can be a SIP-ISUP
Interworking Telephony GW (e.g., MGC - signaling entity) or a SIP-H.323
Interworking GW (e.g., IWF - signaling entity).

REQ 8- I really think the gwreg protocol should be extensible, even if we
aren't sure how we'd like to extend it at the moment. As for whether these
attributes are attributed to routes or gateways, I'd actually suggest a
third alternative for consideration - trunk groups. My carrier architecture
provides a few examples of how such dynamic data depends on trunk groups
rather than gateways.

[RRR] You are right and protocol MUST be flexible enough to accommodate this
(i.e., protocol must NOT be hard-wired for a particular thing). For example,
when we say that a GW registers addresses, the addresses can be E.164, email
IDs, URL IDs, etc. as appropriate.

REQ 11- I'm not sure I entirely understand either the requirement or the
open issue here, but I'll take a stab at this. Since we're considering gwreg
in the absence of intradomain route propagation, independent routing
policies amongst multiple proxies in an ITAD seems like an unlikely issue to
address - any system in which there's a possibility that there are
independent proxies that could somehow be synchronized requires something
like routing policy centralization or intradomain propagation.

[RRR] Again, I think that you are right on this issue because the whole
point is that it is an intra-ITAD situation and, we are NOT considering, as
you have clarified, the intra-ITAD (or intradomain) "route propagation."
Therefore, as you have explained, independent routing policies among the
multiple proxies does NOT arise. 

Is the assumption here that if there are multiple proxies in an ITAD, that
some gateways register with one proxy, and some gateways register with
another, perhaps depending on a POP at which the gateways are located?
(Also, is there a latent requirement here about the cardinality of the roles
of gateways and proxies?) Clearly if two proxies in an ITAD do not
communicate with one another, and each gateway registers with a single proxy
at a time (discounting failover), then I don't think it would even be
possible for two proxies to return the same decision. If allowing something
along these lines is what this requirement signifies, then I definitely
support it.

[RRR] For all practical purposes, there will be multiple proxies (/location
servers) in an ITAD and, we have to develop our protocol keeping this very
practical situation in mind. Otherwise, the protocol will NOT be complete
and will almost be useless because it will NOT work in a real networking
environment where multiple proxies/location servers are a reality. 

[RRR] The other thing is that the protocol messages that will be used
between the GWs and the LSs, the same messages can also be used among the
LSs to serve the purpose. It can be seen examining the contributions that
have been made addressing this problem.

On another angle of this, perhaps support for some sort of load-balancing
should be its own requirement, since I'm not sure that's entirely dependent
on multiple proxies - I'd suggest that a single proxy should be capable of
returning different routes for two calls targeting the same address if it
has received multiple gateway registrations matching the parameters of the
call that have the same preference. Nor do I understand why a database
protocol would preclude load-balancing...

[RRR] Yes, I agree with you.

REQ 12- I'm not really sure why this sort of 'discovery' would be needed. I
agree that static configurations are more likely. Also, I  envision that
either the gateway or the proxy could initiate the connection. For the sort
of architecture I have in mind, it would make more sense to statically
configure the gateway with one or more proxies (each probably associated
with a preference) to which the gateway would attempt to connect.
Cryptographic authentication could let the proxy guarantee that the
connection is desirable.

[RRR] Jon, I beg to explain a little bit. Like REQ 6, as you have also
mentioned, the AUTO-discovery is helpful as opposed to static
configurations. However, as Jonathan mentioned (and we have also seen
examining the several contributions made in this area), the full-fledged
auto-discovery may change the basic characteristics the entire protocol and,
some may not like this.

[RRR] I may tend to consider the auto-discovery as a separate item from the
rest of the protocol development. For example, unicast-schemes (as opposed
to multicast schemes) using DNS look-up may also be considered for ease of
implementation, if it is considered that the multicast-based discovery
mechanism is problematic.

[RRR] The bottom line is that I may agree with you and Jonathan now, if we
agree that we will visit this issue later once we finish the work of the
base protocol that will be used within the intra-ITAD (or intradomain)
excluding the discovery.

Jon Peterson
NeuStar, Inc.

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Dec 2001 02:04:25 -0600

While I don't want to comment extensively on matters that aren't in the
current scope of the WG, I do agree that we need to be somewhat flexible
about how we understand the term 'gateway'. For example, I think most IP
PBXs could qualify as gateways - but the H.323-SIP gateway sounds like a
tougher case to support. As I understand it, the current restriction in WG
scope is intended to prevent us from straying into subjects like service
registration. Perhaps we need some sharper way of defining gateways; maybe
we could rely on the device having a PSTN circuit switched interface as a
litmus test. I would note that if your 'gateways' are propagating
information about email addresses and so forth they go beyond the
capabilities I commonly associate with a gateway.

I also think we agree that there is no obvious reason why the same protocol
needs to be used for the discovery and registration. Personally, I would be
happy to solve the registration problem prior to investigating discovery -
but then again, there may be an overwhelming public sentiment that these two
capabilities have an equal priority or that they need to wrapped into the
same protocol. If there is any reason why these two features should be
tightly coupled, I for one would like to understand it. 

Jon Peterson
NeuStar, Inc.

> From: Roy, Radhika R, ALCTA [mailto:[email-masked]]
> Sent: Monday, December 03, 2001 6:09 PM
> To: Peterson, Jon; [email-masked]'
> Subject: RE: [IPTEL] iptel-gwreg-req open issues
> 
> 
> Hi, Jon:
>

---

From: [email-masked]
Date: Tue, 4 Dec 2001 08:33:26 -0500

>> EQ 8- I really think the gwreg protocol should be extensible, even if we

Just as a clarification point - there are two alternatives to an
iptel-gwreg solution
based on the requirements:

(A) are we discussion some XML document that the SIP GW will provide it's
registrar
in REGISTER and other (e.g. INFO) verbs, potentially sending all
information when
first registering and a delta later when some of the information changes.

or

(B) a new protocol (e.g. TRIP+ or whatever) used between SIP GWs and their
registrars

I would strongly recommend option (A) - SIP GWs register with some network
element,
provide keep-alive etc, and the additional information that needs to be
provided can
be broken down into three types:

1-Capabilities:
  * I have 20 T1 trunks running PRI
  * I can handle G.723.1 and G.711
  * ...

2-Status:
  * I am at 90% now, stop sending me calls
  * 30 of my 60 lines are about to go down for maintenance in 5 minutes
  * ...

3-PSTN Termination:
  * I can terminate to +1212 and +1201 and +1609 with some additional
    metric (as Henning suggested) that has some private carrier
interpretation.

all of these can be defined as an XML document, + allowing a subset of the
document to
be sent when only part of the information changes.  XML also allows for
adding non-standard
capabilities, status elements and termination information pretty easily.

and I would recommend that we do not invent a new protocol here.
Propagation of this
XML should be using SIP and not some "other" protocol.

- gur

BTY, This reminds me of a discussion I had with Joerg Ott 2 years ago on
the need for
capabilities exchange mechanism in SIP - I guess we just had to wait :-)

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Wed, 5 Dec 2001 18:51:42 -0500

[Re-sending it assuming this did not go through as I did not receive a copy from the reflector. My apologies if anyone gets more that one copy.]

-----Original Message-----
From: Roy, Radhika R, ALCTA 
Sent: Tuesday, December 04, 2001 7:34 PM
To: 'Peterson, Jon'; [email-masked]'
Subject: RE: [IPTEL] iptel-gwreg-req open issues

Please see my comments inline [RRR].

By the way, let me also make a proposal that both ITRP and TRIP-GW draft can be combined to make it a subset of TRIP through modifications that can be used for the intra-ITAD communications. In this case, we get an excellent uniformity in protocol for both intra-ITAD and inter-ITAD [TRIP] that uses the same message formats.

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Tuesday, December 04, 2001 3:04 AM
To: Roy, Radhika R, ALCTA; [email-masked]'
Subject: RE: [IPTEL] iptel-gwreg-req open issues

While I don't want to comment extensively on matters that aren't in the
current scope of the WG, I do agree that we need to be somewhat flexible
about how we understand the term 'gateway'. 

[RRR] Let us discuss this in "quantitative" manner for the intra-ITAD communications. In our case, a GW provides protocol conversion between SIP and other protocol (ISUP, H.323, or BICC, etc.) and will have to deal with two important parameters: 1. (Primarily) Addresses and 2. Capacity (if applicable).

For example, I think most IP
PBXs could qualify as gateways - but the H.323-SIP gateway sounds like a
tougher case to support. 

[RRR] Why do you think that SIP-H.323 GW is a tougher case to support? 

[RRR] The specifications and characteristics of the SIP-H.323 GW may be a sub-set than those of the SIP-ISUP GW. May be we need to add few more fields in the address space. All we need to do is use a protocol for "registration" of the GWs. I believe that IETF cannot afford to build one "registration" protocol for SIP-ISUP GW, another for SIP-H.323 GW, another for  SIP-BICC GW, and so on while the same protocol can be used. That is why, all of us have agreed that the protocol needs to be extensible.

As I understand it, the current restriction in WG
scope is intended to prevent us from straying into subjects like service
registration. 

[RRR] Yes, "service" registration is completely different from that of the GW registration. (BTW, if you are interested to work on service registration, let us define the scope of work of the service registration and its functional requirements. We can go from there because it has different context. I have some interest to look into it.)

Perhaps we need some sharper way of defining gateways; maybe
we could rely on the device having a PSTN circuit switched interface as a
litmus test. 

[RRR] I have provided a simpler definition as stated above. We can start to iterate it from there. 

[RRR] (Per your suggestion, if we take SIP-ISUP GW as a litmus test, it will have the attributes like telephone addresses [only E.164 and their family] and circuit capacity [with many parameters]. A SIP-H.323 GW will have telephone addresses, email IDs, URL IDs, etc. (and may be capacity - as simple as port numbers.)

I would note that if your 'gateways' are propagating
information about email addresses and so forth they go beyond the
capabilities I commonly associate with a gateway.

[RRR] A GW provides the association of the addresses when a call comes to it and addresses are provided on the call signaling messages. So, it is the application that decides what kinds of addresses will be there and the location server (in our case) will decide which GWs the calls need to be destined for those destination addresses. So, this is a simple generalized logic. (For example, ITU-T Rec. H.225.0 Annex G can be seen how all kinds of addresses are taken care of. The draft-roy-iptel-itrp-00 can also be seen for this purpose.)

I also think we agree that there is no obvious reason why the same protocol
needs to be used for the discovery and registration. 

[RRR] It is always better to use the same protocol. If it is a problem, people need to quantify it. (I have provided contribution draft-roy-iptel-itrp-00 that uses the same protocol. Is that a problem? All I have said that we may keep the "discovery" mechanism away for the sake of making progress for now. We can use this one later either using the same protocol or different protocol.)

Personally, I would be
same protocol. 

[RRR] The draft-roy-iptel-itrp-00 wrap this two into the same protocol. (Personally, I do not see any problems.)

If there is any reason why these two features should be
tightly coupled, I for one would like to understand it. 

[RRR] The only reason that I see that there is a benefit to use the same protocol suit to minimize the protocol development and to make easy for implementation. 

[RRR] By the way, let me make a proposal that both ITRP and TRIP-GW draft can be combined to make it a subset of TRIP through modifications that can be used for the intra-ITAD communications. In this case, we get an excellent uniformity in protocol for both intra-ITAD and inter-ITAD [TRIP] that uses the same message formats.

Jon Peterson
NeuStar, Inc.

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 4 Dec 2001 19:34:04 -0500

By the way, let me also make a proposal that both ITRP and TRIP-GW draft can
be combined to make it a subset of TRIP through modifications that can be
used for the intra-ITAD communications. In this case, we get an excellent
uniformity in protocol for both intra-ITAD and inter-ITAD [TRIP] that uses
the same message formats.

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Tuesday, December 04, 2001 3:04 AM
To: Roy, Radhika R, ALCTA; [email-masked]'
Subject: RE: [IPTEL] iptel-gwreg-req open issues

[RRR] Let us discuss this in "quantitative" manner for the intra-ITAD
communications. In our case, a GW provides protocol conversion between SIP
and other protocol (ISUP, H.323, or BICC, etc.) and will have to deal with
two important parameters: 1. (Primarily) Addresses and 2. Capacity (if
applicable).

[RRR] The specifications and characteristics of the SIP-H.323 GW may be a
sub-set than those of the SIP-ISUP GW. May be we need to add few more fields
in the address space. All we need to do is use a protocol for "registration"
of the GWs. I believe that IETF cannot afford to build one "registration"
protocol for SIP-ISUP GW, another for SIP-H.323 GW, another for  SIP-BICC
GW, and so on while the same protocol can be used. That is why, all of us
have agreed that the protocol needs to be extensible.

[RRR] Yes, "service" registration is completely different from that of the
GW registration. (BTW, if you are interested to work on service
registration, let us define the scope of work of the service registration
and its functional requirements. We can go from there because it has
different context. I have some interest to look into it.)

[RRR] I have provided a simpler definition as stated above. We can start to
iterate it from there. 

[RRR] (Per your suggestion, if we take SIP-ISUP GW as a litmus test, it will
have the attributes like telephone addresses [only E.164 and their family]
and circuit capacity [with many parameters]. A SIP-H.323 GW will have
telephone addresses, email IDs, URL IDs, etc. (and may be capacity - as
simple as port numbers.)

[RRR] A GW provides the association of the addresses when a call comes to it
and addresses are provided on the call signaling messages. So, it is the
application that decides what kinds of addresses will be there and the
location server (in our case) will decide which GWs the calls need to be
destined for those destination addresses. So, this is a simple generalized
logic. (For example, ITU-T Rec. H.225.0 Annex G can be seen how all kinds of
addresses are taken care of. The draft-roy-iptel-itrp-00 can also be seen
for this purpose.)

[RRR] It is always better to use the same protocol. If it is a problem,
people need to quantify it. (I have provided contribution
draft-roy-iptel-itrp-00 that uses the same protocol. Is that a problem? All
I have said that we may keep the "discovery" mechanism away for the sake of
making progress for now. We can use this one later either using the same
protocol or different protocol.)

Personally, I would be

[RRR] The draft-roy-iptel-itrp-00 wrap this two into the same protocol.
(Personally, I do not see any problems.)

[RRR] The only reason that I see that there is a benefit to use the same
protocol suit to minimize the protocol development and to make easy for
implementation. 

[RRR] By the way, let me make a proposal that both ITRP and TRIP-GW draft
can be combined to make it a subset of TRIP through modifications that can
be used for the intra-ITAD communications. In this case, we get an excellent
uniformity in protocol for both intra-ITAD and inter-ITAD [TRIP] that uses
the same message formats.

Jon Peterson
NeuStar, Inc.

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 4 Dec 2001 19:34:04 -0500

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Tuesday, December 04, 2001 3:04 AM
To: Roy, Radhika R, ALCTA; [email-masked]'
Subject: RE: [IPTEL] iptel-gwreg-req open issues

Personally, I would be

Jon Peterson
NeuStar, Inc.