[cisco-voip] CUBE Configuration

[Ki Wi]

I'm wondering will this happens?

If the callmanager are source from different ip address such as 10.1.0.10 on the left and 10.1.1.10 on the right. From cube point of view, it should be translating everything (signalling and Rtp) into it's WAN ip for the opposite endpoint to communicate with. At the same time, it should be able to track/differentiate both side with diff session/ sequence number.

Sent from my iPhone
Pls pardon my fat fingers.

On Nov 9, 2010, at 6:30 PM, "Ahmed Elnagar" <ahmed_elnagar at rayacorp.com> wrote:

> Yes exactly…that is what I have been thinking of is that the diagram is not correct…each side should have a CUBE in order to support this scenario…the other solution is VRF and it won’t work as VRF-configuration per dial-peer is not supported.
> 
>  
> 
>  Best Regards;
> 
>   Ahmed Elnagar
> 
>   Senior Network PS Engineer
> 
>   Mob: +2019-0016211
> 
>   CCIE#24697 (Voice)
> 
>  <image003.jpg>
> 
>  
> 
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nick Matthews
> Sent: Tuesday, November 09, 2010 1:43 AM
> To: Peter Slow
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] CUBE Configuration
> 
>  
> 
> I think this is a simplified version of a picture that CUBE is used for.  CUBEs are used for overlapping IP address spaces, but not like this.  Generally you'll have something like 10.x network -> CUBE-> DMZ->CUBE->10.x network.  I've seen this for mergers and the likes, where you've got a CUBE on the side of each company.  You route over the DMZ on certain phone prefixes, etc.
> 
> This would not be a working scenario.  Pete is right that it only supports one VRF, and even then it doesn't support overlapping IP addresses between the global table and the VRF.  This picture should have two CUBEs in it.
> 
> -nick
> 
> On Mon, Nov 8, 2010 at 5:14 PM, Peter Slow <peter.slow at gmail.com> wrote:
> 
> Tim,
>    Did you look at the IP addresses on the two phones involved in the scenario?
> -Pete
> 
>  
> 
> On Mon, Nov 8, 2010 at 4:58 PM, Tim Smith <smithsonianwa at gmail.com> wrote:
> 
> And yes the scenario does work. I've got it running for a Skype Connect SIP trunk at the moment.
> 
> Cheers,
> 
> Tim.
> 
>  
> 
> On Tue, Nov 9, 2010 at 8:57 AM, Tim Smith <smithsonianwa at gmail.com> wrote:
> 
> I'm only just starting out on CUBE to be honest.
> 
> You can have both flow through and flow around modes for the media.
> 
> Flow through as below.. actually re-originates the signalling and media from the CUBE's IP address.
> So it's basically like a HTTP proxy server for example.
> 
> To make it the networks on each side of the CUBE, just need to be able to reach the CUBE itself. 
> 
> They do not need to see the other network directly.
> 
> Cheers,
> 
> Tim.
> 
> On Tue, Nov 9, 2010 at 8:09 AM, Ahmed Elnagar <ahmed_elnagar at rayacorp.com> wrote:
> 
> Dear all;
> 
>  
> 
> This slide is from CVOICE course…I need to know is it possible from a routing perspective…can these two phones communicate through the CUBE normally?...how the routing table would look like on the CUBE router?
> 
>  
> 
> <image004.png>
> 
>  
> 
>   Best Regards;
> 
>   Ahmed Elnagar
> 
>   Senior Network PS Engineer
> 
>  
> 
> <image005.jpg>
> 
>   RAYA Building El Motamiez District, 6th of October, Egypt
> 
>  
> 
>   Mob: +2019-0016211
> 
>   Phone: +202 3827 6000 Ext.2475
> 
>   Website: www.rayacorp.com
> 
>   E-mail: ahmed_elnagar at rayacorp.com
> 
>   CCIE#24697 (Voice)
> 
>  <image003.jpg>
> 
>  
> 
>  
> 
> Disclaimer: NOTICE The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Raya will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any malicious code or virus being passed on. Views expressed in this communication are not necessarily those of Raya.If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message.
> 
>  
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
>  
> 
>  
> 
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
>  
> 
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
>  
> 
>  
> Disclaimer: NOTICE The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Raya will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any malicious code or virus being passed on. Views expressed in this communication are not necessarily those of Raya.If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message.
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20101110/ee6ac3be/attachment.html>