Subject: Re: [Speermint] Speermint Charter

From: "Stastny Richard" <[email-masked]>
Date: Fri, 31 Mar 2006 00:07:00 +0200

Hi Reinaldo,
 
inline
 
>>
>> >I responded to soon before.  You have a good point.  So what you are
>> >suggesting is peering can encompass multiple SIP based services (P2P,
>> >ENUM, SIMPLE, etc.), and should not be limited to basic SIP
>telephony?
>> >
>> >Thanks...
>>
>> Thank you for bringing this up again and in focus
>>
>> The basic idea of SPEERMINT is to bring an SIP INVITE from Provider
>> (or admin domain) A to B without immediately being rejected.
>[[Reinaldo]]
>
>Hello Richard,
>
>If all we need is what you said above, then what we need is already
>defined in SIP/SIPPING, right? They already standardized procedures for
>DNS lookup, etc, etc
>
>Let me rephrase the question by asking what is missing instead of what
>is already defined. If we have two SIP domains, with the DNSs properly
>SIPpenized, where the SIP border proxies are configured to talk to each
>other, is there anything else needed besides what is in SIP/SIPPING?
>
>Is the policy piece the missing link?

I think so. And eventually a profile and minimum requirements for interconnect

>Sorry, I'm trying to peel another layer to look under "enabling to SIP
>messages between the two domains", "Layer 5 peering" and other
>expressions.
>
>I'm trying to understand what exactly is missing if all we want is to
>enable Sip messages from domain A to reach B. Are today VoIP peering
>points just exchange of media or there is signaling going on as well?

Either signaling only or also signaling+media (called SBC)
>
>I think we should rephrase the charter to be much, much more specific on
>what our goals are, the drafts we need and milestones.

Yes, and I think this discussion helped very much to make this clear

>Thanks,

Thank you
Richard

Reinaldo

>
> If one follows this discussion, one gets the impression that the
buzzwords
> immediately are traffic, QoS, managed networks, billing, accounting,
> charging,
> so basically the main task of the SIP INVITE seems to trigger a meter.
>
> So most here are immediately putting their Bell-hat on and thinking
voice
> calls
>
> But at that point of time it is not even defined what the purpose of
the
> session will be
>
> Of course we are talking about ALL SIP services. Do I need a
guarantied
> QoS
> and managed network for an IM or a filetransfer?
>
> Richard
>
> >Daryl M.
>
>
> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Thursday, March 30, 2006 1:34 PM
> To: Khan, Sohel Q [CTO]
> Cc: [email-masked]
> Subject: Re: [Speermint] Speermint Charter
>
> Hi Sohel,
>
> This is no so simple
>
> 1. P2P SIP has a complete different charter
> 2. What if a P2P network is provided by a provider who wants to peer
> with another provider?
>
> Richard
>
> ________________________________
>
> Von: Khan, Sohel Q [CTO] [mailto:[email-masked]]
> Gesendet: Do 30.03.2006 22:03
> An: Khan, Sohel Q [CTO]
> Cc: [email-masked]
> Betreff: [Speermint] Speermint Charter
>
>
>
> IMHO,  IETF community wants to solve VoIP peering problem in two major
> ways: e2e/p2p and interprovider/interdomain.
>
> I hope that IETF will try to address those separately as follows:
>
> P2P SIP BOF/WG:  E2E/p2p peering
>
> SPEERMINT WG: Interprovider/interdomain peering
>
>
>
> Thank you.
>
> Sohel Khan
>
>
>
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
>
>
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
>
>
> _______________________________________________
> 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: Thu, 30 Mar 2006 17:38:41 -0500

Wading in the middle:

Just for fun, I re-read our charter.  I came away saying "that's pretty
clear".  I now turn to this discussion and say "please re-read the charter".

The charter is clear we are talking about all forms of real time
communications.  The charter doesn't explicitly rule out one way (streaming)
but I think we can assume it.  So, it's not just voice.

The charter is clear we are talking about SIP.  We aren't talking about XMPP
for example or H.323.  The charter does not discuss p2p SIP.  I believe that
until there is a working group on p2p SIP, and until that group produces
some interesting results, it's out of scope for us.  We're dealing with
proxy to proxy peering.

The charter is pretty clear that we are talking about BOTH inter-carrier as
well as any inter-domain peering.  I suppose it could be clearer about that
point.  I think inter-enterprise VoIP, to take an example, without benefit
of a carrier, is probably in scope.  We could, within the group, decide to
treat carrier peering and other interdomain peering separately.  It's not
clear to me that we need to or should, at least at the moment.  I don't
think anyone can say "we are NOT working on inter-carrier peering".
Similarly, I don't believe we are limited to e.164 addresses.  I think we
include mapping of e.164s to SIP URIs within our documents as one of the
things a proxy may do.  I think we can also be somewhat cavalier with the
differences between public ENUM, infrastructure/carrier ENUM and private
ENUM.  I don't think we even want to offer guidance on what to do when more
than one is available other than observing that such a case will be common.

The charter is clear we are talking about BOTH the media and the signaling.
If you combine that with "inter-carrier vs inter-domain" then you have BOTH
the case of a direct media connection as well as one that goes through
(horrors) SBCs, even when two UAs are in the same hotel.  Most enterprises
seem to like SBCs anyway.  Unless someone gives me a really good explanation
of why it actually matters if they do run through SBCs with respect to our
work, I think we probably can ignore the difference.

Finally, in my checkered past, I have had many occasions to observe the
difference between a pile of documents that purport to define interoperable
implementations, and the reality of actually achieving it.  While in
general, in the IETF, "profiles" are not a nice word, Best Current Practices
are.  Our charter is clear we are to develop BCPs.   One of the biggest
values we can have on peering is to be VERY explicit about what the (SIP)
signaling looks like across the peering points.  Remember, the wonderful
thing about standards is that there are so many to choose from.  There is no
better example of that than the area in which we find ourselves here, and we
CAN do something about making choices.  It's all well and good to say "dip
ENUM if you have an e.164, use SRV to find the server for the domain of the
URI, send an INVITE there", but, in the real world, it's MUCH more
complicated then that, and our job is to describe all the dreck that you
really have to do.

I think our problem is more to define what we do first then what we do.

Brian

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Thursday, March 30, 2006 5:07 PM
To: Reinaldo Penno; Malas, Daryl; Khan, Sohel Q [CTO]
Cc: [email-masked]
Subject: Re: [Speermint] Speermint Charter

Hi Reinaldo,
 
inline
 
>Is the policy piece the missing link?

I think so. And eventually a profile and minimum requirements for
interconnect

Thank you
Richard