Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

>Francois D. Menard wrote

>>Patrick Melampy wrote:

>> An issue does arise when thinking about PSTN numbers. Since many carriers
>>will have an interface to the PSTN, these are not owned by any domain. Thus
>>we may need to expand support for PSTN reachable numbers somehow? One idea
>>would be to also perform subscribe and notify for partial E.164 numbers
>>similar to how it was proposed in the TRIP protocol.

>I would motion that SPEERMINT only deals with E.164 numbers that are
>acessible across a SIP NNI. Any E.164 numbers that are also reacheable over
>TDM is out of scope.

IMHO SPEERMINT does not deal with E.164 numbers at all in routing, it is out of scope

This is ENUM WG scope

the only issue regading E.164 could be how calls originally originating
and terminating E.164 are dealt with in the header fields in the Signallng
Function

And I definitely do not want to go down the bumpy road using
SPEERMINT to discuss how to interconnect and locate SIP
transit networks for PSTN networks (e.g. using TRIP) 

Richard

-----Original Message-----
From: Otmar Lendl [mailto:lendl@nic.at]
Sent: Friday, May 26, 2006 9:36 AM
To: Patrick Melampy
Cc: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; speermint@ietf.org
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

On 2006/05/24 17:05, Patrick Melampy <PMelampy@acmepacket.com> wrote:
> Subscriptions have other beneficial attributes -- as they can work
> across network boundaries and have context. Subscribe/Notify can
> deliver a policy that corresponds to a reverse flow of SIP traffic.
> Plus the Notification
can
> provide near real time changes. Also very contextual data can be
> included
in
> the notification -- providing a nice mechanism for automatic
> congestion control.
>
> I like DNS providing LOCATION only, and I like the notion of all other
> attributes that have a contextual base to be delivered in a contextual
way.

I think I can see your point.

I still have a serious problem regarding how to bootstrap such a system as

* Carriers seem to hate to expose their SIP ingress elements to the open
  Internet. They firewall, use private address spaces (e.g. GRX) or
  otherwise block incoming SIP calls before they reach the SIP stack.

* we want to avoid a mandatory bilateral configuration of peerings.

Could you sketch how a dynamic peering discovery could work with a SIP
subscription model?

/ol
--
< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint