Subject: [Speermint] Some comments on draft-lee-speermint-use-case-cable-00

From: Otmar Lendl <[email-masked]>
Date: Tue, 4 Jul 2006 15:47:39 +0200

I've just read draft-lee-speermint-use-case-cable-00, and I'd like
to offer some comments to the list.

First of all, thanks for this informative document. Such clear reports on
the current state of affairs are very helpful to focus our discussion.

One thing is unclear to me:

Your basic call setup contains

   1. Perform an ENUM query on the called party in the SIP request URI. 
    
   2. If the ENUM server fails to return the response, SM-o forwards the 
   call to PSTN. 
    
   3. ENUM server returns a NAPTR record. SM-o parses the regular 
   expression and formulates the sip uri of Bob which is <sip:bob@mso-
   t.com>. 
    
   4. SM-o finds out that it does not own "mso-t.com". SM-o has local 
   policies to send the request to PP-o. 
    
   5. SM-o sends a DNS query to locate PP-os IP address. 
    
   6. DNS returns PP-os IP address to SM-o. SM-o sends the SIP INVITE 
   to PP-o. SM-o MAY choose to record-route to stay on the signaling 
   path. 
 
   7. PP-o receives the SIP INVITE. It examines the request URI and 
   sends a query to DNS server to get the IP address of Bobs domain 
   "mos-t.com". 

This seems to indicate that whenever ENUM returns a foreign URI,
the call will be sent via SIP to the responsible PP-t.

In section 6 you elaborate:

   In the call flow shown in Figure 2, when PP-o receives the SIP INVITE 
   request from SM-o, PP-o queries DNS to resolve the IP address of the 
   domain "mso-t.com". PP-o MAY choose not to query DNS server to 
   resolve "mso-t.com". By examining the domain part of Bob's sip uri, 
   SM-o knows that "msoB.com" is one of its trusted peer. In many cases, 
   PP-o's configuration will have static configuration pointing to a 
   static IP address associated to PP-t. There is number of reasons to 
   have this setup. Most common reason is security such that PP-o only 
   peers to the pre-configured IP address. In this setup, PP-o MAY skip 
   querying DNS to resolve the domain name of the remote target. That 
   said, it does not stop PP-o to use DNS to resolve the domain name. 

thus there might be some static configuration regarding the address
of PP-t in the originating network and thus information about peering
partners. 

Questions:

* Do you expect the ENUM to return only answers to queries if the 
  destination MSO is one of the configured peers of the originting MSO?

* Or is there a way in which the PP-o can tell its SM-o that
  "sorry, we don't peer with that destination domain, you need to
  fall-back to PSTN"?

In 8.3 you write:

   This MAY not scale well 
   when an operator tries to peer with few hundred peers. This happens 
   for cable operators provide peering service to large numbers of 
   enterprise customers. Peering security is a working item for the 
   working group. 

So you expect that a MSO will not only peer with other MSOs and other
VoIP operators, but also with enterprises? Is that a case of real peering
(in the sense of a connection between equals) or is that more a
customer/provider relationship (PBX to upstream VoIP-operator)?

-----

Your "Furture Works" section hits the nail on the head. Those are
exactly the areas where the current ad-hoc schemes fail.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 5 Jul 2006 11:15:24 -0400

Hi Lendl,

Thanks very much for taking time to review this draft. Please see inline
for my attempt to answer your questions: 

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, July 04, 2006 9:48 AM
To: [email-masked]; Lee, Yiu
Subject: Some comments on draft-lee-speermint-use-case-cable-00

I've just read draft-lee-speermint-use-case-cable-00, and I'd like to
offer some comments to the list.

First of all, thanks for this informative document. Such clear reports
on the current state of affairs are very helpful to focus our
discussion.

    

   call to PSTN. 

    

This seems to indicate that whenever ENUM returns a foreign URI, the
call will be sent via SIP to the responsible PP-t.

[YL] Yes, this is right

thus there might be some static configuration regarding the address of
PP-t in the originating network and thus information about peering
partners. 

[YL] In our peering trial with CableLabs, we do not rely on DNS lookup.
We always pre-configure the IP address of the target peering device.

Questions:

[YL] Excellent question. In our trial enum server, it only contains
entries for MSO peering points. However, PP-o may not peer with all the
MSOs in day one, so we need to have a way to fall back to PSTN. The way
we handle it today is to ask the PP-o to send back a "404 Not Found" to
SM-o if it doesn't have a pre-configured session to the target domain.
When SM-o receives a 404 from PP-o, SM-o will have a local policy to
fall-back to PSTN. We are also working on a design to ask PP-o to do a
np dip for all unknown call and route the call back to SM-o. 

In 8.3 you write:

   This MAY not scale well 

So you expect that a MSO will not only peer with other MSOs and other
VoIP operators, but also with enterprises? Is that a case of real
peering (in the sense of a connection between equals) or is that more a
customer/provider relationship (PBX to upstream VoIP-operator)?

[YL] Some MSOs have enterprise voice customers. Currently, they sell TDM
trunks to them. In future, I think it makes sense for those MSOs to
offer SIP trunk services to the enterprise customers. For those MSOs,
they will have two types of peering partners: (1) service provider
peering and (2) enterprise customer peering. 

-----

/ol