Subject: Re: [Speermint] Some clarifications

From: "Stastny Richard" <[email-masked]>
Date: Thu, 9 Feb 2006 21:43:00 +0100

>I think besides peer policy which may be mostly static, there are more
>dynamic reasons why calls may be rejected, for example capacity and
>bandwidth limitations which change at runtime. Sometimes routes may also
>change fast enough that a more realtime solution than DNS may be
>desirable. Since the priority#1 is E.164/VoIP peering, TRIP came to my
>mind and I want to hear from people on the list as to what they think
>about it.
 
>From the charter:
"Note that the term "peering" is used here to refer to
the interconnection between application layer entities such as
SIP servers, as opposed to interconnection at the IP network
layer. However, in order to achieve real-time Session PEERing,
both signaling and media flows must be taken into
consideration."
 
capacity and bandwidth limitations, fast route changes, etc are therefore 
within the scope of SPEERMINT, but I also read this text that first
priority is the signalling on the application layer, and here fast
route changes do not apply.
 
IMHO SPEERMINT should first concentrate on the basics, enabling
peering at the application layer, and if this is implemented and works,
we may move forward to the issues you mentioned.
 
regards
Richard

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

---

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Thu, 9 Feb 2006 15:51:57 -0500

Re
>> I don't think an ENUM based solution is elegant.

I'd beg to differ. TRIP and TGREP are essentially
code(number-prefix)-based solutions. They don't scale well with number
portability unless you keep a separate NP database around (which carrier
ENUM will eventually allow you to dispense with) They don't really
reflect carrier-of-record relationships but just who has a route
(usually a gateway). So long-term, do they really make sense when
delivery to PSTN gateways is not the modal scenario?
 I think of layer 3 peering as generally delivering traffic to the SP
whose customer the traffic is destined for. TRIP isn't really oriented
to that.

So, while TRIP/TGREG have an aesthetically pleasing symmetry with IP
routing protocols I don't think they're the wave of the future.

Penn Pfautz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Medhavi Bhatia
Sent: Thursday, February 09, 2006 3:12 PM
To: Duane
Cc: [email-masked]
Subject: RE: [Speermint] Some clarifications

Hi Duane,

> Medhavi Bhatia wrote:
> >>> I am wondering if things like TRIP/TGREP have been considered
> >>> as well (or modifications thereof).
> >> 	While I'm not really sure what you are asking here, it is
> >> 	certainly the case that if we wind up with use cases that
> >> 	require TRIP, for example, then yes.
> >>
> >
> Aren't such notifications already built-in into existing protocols
such
> as SIP?

I am not aware of any. There are two use cases:

Routing: TRIP can provide more realtime information on Routing. I think
ENUM has significant advantages as well and maybe a combined approach
can be devised

Bandwidth/Capacity etc: I don't know of any notifications built into SIP
at this point, but I remember TGREP being used to advertise some of this
information to peers. 

Cheers,
-Medhavi. 

> --
> Best regards,
>   Duane