[c-nsp] Voice Vpn

[Saku Ytti]

On (2007-01-30 08:50 +0000), david.ponsdesserre at uk.bnpparibas.com wrote:
> Hello all .
> 
> I had a look and the web site archives without any luck ....
> I am looking for best practices on how to implement a voice over Ip  Vpn 
> (over Cisco Mpls network) .

It's not immediately obvious to me how this is different to implementing
VoIP on Internet table. Of course in transit you do QoS based on MPLS EXP
instead of DHCP/prec, but the difference is hardly worth discussing
(if one understands QoS in Internet, which I claim not to) as it's just different
match statement in class-map.

I'm not sure what kind of service you have in your mind, but if it's IP to
IP throughout the Internet, then obviously VRF has little to do with it.
 If it's closer to hosted and shared IP-PBX, which mostly acts as PSTN-GW,
rather than IP to IP calls, then I might be able to say something.

In latter example, your problem probably is, you have VRFs that are 
completely separated, but you can't afford to deploy dedicated SIP
proxy/PSTN-GW/hosted IP-PBX solution per VRF, but VRFs must be
able to share this service.
 Right from the start this is compromise to the security of the VRF, and
as a community we surely want our customers to believe in VRF as a product.
So if you do any services where VRF's are combined, inform the customer
about the security implications of buying the service to VRF. (Even VRF
MGMT is compromise to the VRF product)
 Now, I can think of two main strategies of doing this.

1) Have VoIP RTs, eg 42:1 hosted VoIP server/services, 42:2
   VoIP customers phones/pbx's. 
   Export SIP proxy, PSTN-GW, hosted IP-PBX etc with 42:1
   and import that 42:1 to customer VRF's who have bough
   the service.
   Export 42:2 for the CIDR from customer net, where
   connectivity to VoIP is required (phones, PBX) and
   import 42:2 to the VRF where VoIP equipment are.

2) If you also sell same service to Internet users, 
   you either need sip-proxy/pstn-gw to have two interrfaces 
   (subinterfaces will do) VRF select or tunneling to reach
   Internet and VRF from same VoIP gear. After this, it's much
   the same as above.
   Alternatively what you could do, is add route to the customer
   phones  and PBX in Internet table as very specific routes,
   and you need to import sip-proxy/PSTN-GW routes to VRF
   from Internet table. Effectively combining VRF and
   Internet tabales, but only for the prefixes where it's
   required.
   Unidirectionally everyone from Internet could reach
   the phones and PBX in customer VRF, if you do not
   have ACL in place.


-- 
  ++ytti