Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 23 May 2006 16:32:13 -0400

Brian,

I think the the interworking of SIP to PSTN is out of scope here.  The
issue is whether two peers, once they have discovered each other, can
know what subset of SIP they need to support.  I don't think there is
any need to go down the rabbit hole on what applications are supported
and whether they are PSTN emulations or simulations or whatever.  We may
know in the back of our mind that some application won't work if RFC X
is not supported, but we don't need to discuss that.  We need only to
focus on what SIP RFCs are needed on the SIP peer interface.

While coloring within those lines, the next question is whether there is
a single subset that can be defined or whether there will be many.  I am
betting on many, probably a different set for each federation or even
bilateral pairing that might exist.  That could be another rabbit hole.
I would be happy if two peers could point to the same subset and agree
to use it, no matter how many subsets might exist.

Mike

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Tuesday, May 23, 2006 3:05 PM
> To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, 
> Sohel Q [CTO]'; 'David Meyer'; [email-masked]
> Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> By far the largest mistake EVER made by the IETF in the 
> development of SIP was to allow SIP to be extended to imitate 
> the existing PSTN.  If we ever were to start again, the 
> golden rule would be DON'T IMITATE THE PSTN, and the 
> corollary would be "Just because the PSTN does it that way 
> DOES NOT MEAN it's a good idea".
> 
> So, the very idea that "replication of functionality in the 
> SS7 minimum message set" is the definition of what we need to 
> do makes me want to puke.
> 
> No, and a pox on your houses for even thinking that.
> 
> While we're going to start with "basic call", we need to 
> define those call features that must cross domain boundaries. 
>  Most of them have existing SIP messaging (in sip-examples, 
> for instance).  We need to make sure those features work 
> across the boundary.  That has nothing whatsoever to do with 
> an SS7 message.  The mms might give us clues on what features 
> might be interesting to put on our list, but I'll bet we end 
> up with a lot less of them, and a bunch of stuff not in SS7 
> (or C7); inter-domain presence, for example.
> 
> Brian
> 
> -----Original Message-----
> From: Francois D. Menard [mailto:[email-masked]]
> Sent: Tuesday, May 23, 2006 2:50 PM
> To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; 'David 
> Meyer'; [email-masked]
> Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> > I don't see anything diametrically opposed between what I suggested 
> > and
> what you are suggesting.  
> 
> I would be satisfied with this:
> 
> SPEERMINT compliance requires replication of the 
> functionality available in the SS7 minumum message set which 
> can be done by SIP, 3323, 3325.  Better than SS7 mms 
> functionlality made possible with ATIS, IP Sphere or other 
> sip profiles will also be considered as SPEERMIT compliant.
> 
> > If there is to be an IETF-approved SIP profile, I think it should 
> > first be
> decided if that is the turf of the Speermint or the SIP WG.
> Those last two statements are at the heart of my concerns.
> 
> SPEERMINT will be completely toothless as an RFC if it just 
> states, compliance with SPEERMINT can be achieved by 
> compliance with non-IETF standards.
> 
> F.
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 23 May 2006 16:49:35 -0400

I mostly agree, but you have to decide what is in the set of RFCs, and to
me, that is what call features are supported.  So, I don't want to see an
argument that says "we have to implement RFC xxxx because I like the
author".  I want to say "because we agree such and such feature works across
the peering point, we must implement RFCs x, y and z".

Dunno whether we need more than one list.  Try for one and see what happens,
back off if you can't get consensus.

Brian

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Tuesday, May 23, 2006 4:32 PM
To: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer;
[email-masked]

Brian,

Mike

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 23 May 2006 22:59:10 +0200

On 2006/05/23 22:05, "Michael Hammer (mhammer)" <[email-masked]> wrote:
> know what subset of SIP they need to support.  
[...]
> to use it, no matter how many subsets might exist.

Well, I've got a draft to sell to you.

>From the example section of draft-lendl-domain-policy-ddds-00.txt:

   o  If the carrier example.com only accepts SIP calls (in addition to
      PSTN interconnect) if the PSTN emulation is good, he might publish
      a policy like this:

      $ORIGIN example.com.
      ;      order pref flags service regexp replacement
       IN NAPTR 10 10   "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3578!" .
       IN NAPTR 10 11   "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3666!" .
       IN NAPTR 10 12   "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3960!" .

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

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 24 May 2006 01:45:54 -0400

> know what subset of SIP they need to support.  

Oh goodie ... finally we can get the SIP working group to try and define a
rational set of SIP Profiles so SPEETMINT can use them do discover what
subsets of SIP they can support.

Talk about going down black holes ...