Re: [Speermint] Meeting minutes from IETF 73 Speermint session (Arch Draft Review)

["James McEachern" <jmce at nortel.com>]

Architecture Draft Review - Part 2

This email continues the detailed review of the Architecture Draft
Review from the point where I left off on my first email.

1. Section 5.1.1.2.  User ENUM Lookup
This section refers to the "peer" in several places.  This should be
changed to "SSP"

2. Section 5.1.1.2 User ENUM Lookup
This section states that "... the initiating peer [change to
"originating SSP] consults the public "User ENUM" ..."

I fully expect to be overruled here, but I strongly believe that the
query to User ENUM should be subject to local policy, one important
aspect of which would be the explicit preferences of the originating UA.
I would prefer to change "consults" to "may consult" - but as I say, I
am resigned to being overruled, if not flamed. 

3. Section 5.1.1.3. Infrastructure ENUM Lookup
Change "initiating peer" to "originating SSP" and "peer" to "SSP"
(several times).
Change "carrier ENUM" to "Infrastructure ENUM".

4. Section 5.1.2. Location Routing Function (LRF)
Change "Initiating SSP" to "Originating SSP".

This section also states that the LRF analyses the target address and
discovers the next hop...  I believe that the analysis includes the
target domain that was identified by the LUF.  Therefore, with these two
changes, I suggest this section should read:
"The LRF of the Originating SSP analyses target address and target
domain, identified by the LUF, and discovers the next hop signaling
function (SF) in the peering relationship. ..."

5. Section 5.1.2.1. Routing Table
I have several issues with this section.  
First of all, I think it should be moved to after 5.1.2.2 SIP DNS
Resolution, since you should only be performing PSTN breakout if SIP DNS
resolution fails.
Change "initiating" to "Originating", and "peer" to "SSP" throughout.

I believe that the third paragraph should be deleted.  The first
paragraph states that this section applies when you "cannot discover the
carrier-of-record or ... cannot reach it via SIP peering" and then this
paragraph goes on to say you should forward to the target SSP using sip
peering. Just doesn't make sense.

The text beginning with the "Note" does seems confusing to me.  How
about starting a new paragraph at that point, and use the following text
(through to the new end of this section).
"Note that the Originating SSP may still forward the call to a PSTN
gateway in another SSP by prior arrangement using the routing table.  If
so, the Originating SSP may rewrite the Request-URI to address the PSTN
gateway and may forward the request to that SSP using SIP procedures."

6. Section 5.1.2.2 SIP DNS Resolution
As said earlier, this should go before the Routing Table section.
This section also introduces a new term, the "receiving peer".  This
should be changed to "Target SSP".

7. Section 5.1.2.3 SIP Redirect Server
I am not at all certain this section adds value.  I would delete it.

8. Section 5.1.3 The Signaling Function
The first paragraph states that the SF can optionally perform
termination and re-initiation of a call, but the second paragraph states
that this is performed by the SBE.  Which is it?  The third paragraph
also says the SF can process SDP payloads, which makes it a B2BUA.  As I
understand it, a B2BUA includes an SF (two actually) but an SF does not
include a B2BUA.

I think the problem is that this section is really describing the SBE,
which includes one or more signaling functions.  Calling it the SF just
confuses the issue - or at least it confuses me.  Why not just call a
spade a spade, and write this section as the SBE that can include
signaling function, modify SDP, etc.

9. Section 5.1.3.1.1 TLS connection
This section states that "the initiating [should be "Originating"] SSP
will open ... TLS connection".  I would prefer to change "will" to "can"
since there are circumstances where it is permissible to use IPSec
rather than TLS.

10. Section 5.1.3.1.3 Co-Location
Says that messages "would" be sent as clear text. I think it would be
better to say they "could" be sent as clear text.

11. Sections 5.1.3.2 and 5.1.3.2.1
Change "peer" to "SSP" - in several places.

---- end of second comments email -----

 

Jim McEachern
T:+1 613 763-3419
M:+1 613 853-0176