Like we have call manager cluster and two sites (main and remote). One call calls into the remote site gateway DID, this DID goes to one extension in remote site. Right now, we would like configure gateway DID to go to one extension in main site and then get that extension in main site forwarded to the extension in remote site (just try to have traffic going through main site and back to remote site). My question is whether the RTP traffic will flow through the main site. Is there any possility that Call manager just tells gateway in remote site about the IP address of extension in remote site when call manager checks the forwarding setup? If so, the RTP traffic may only happens between gateway and extension in remote site.
I may confuse you guys. Let me put it simple, if I setup a call forward from extension A to extension B, does the RTP traffic goes to extension A and then to extension B. Or the calling party directly go to the extension B?
2. HQ-Gateway determines (H323/sip) or is told (MGCP) to send the call to the CUCM for the next routing decision
3. CUCM determines that the HQ-Phone is the target station and checks a cached forwarding table to see if the phone extension is in the forwarding table
4. In your scenario, the HQ-Phone extension is in the forwarding table and it is forwarded to the Remote-Phone
5. The CUCM sends call setup information to the Remote-Phone which causes it to "ring". At the same time the CUCM instructs the HQ-Gateway to send alerting indication back to the caller (so they hear ring back)
6. When the Remote-Phone answers, the RTP stream will flow from the HQ-Gateway to the Remote-Phone. The RTP stream never flows to/through the HQ-Phone but does need to traverse your WAN connection
Since the call is coming from the PSTN the only way you could keep the RTP stream off of your WAN is to redirect the call (hairpin) back through the PSTN to the remote gateway. ISDN-PRI has no way to release the call so, for the duration of the call your HQ-Gateway would have two B-channels used. Which is also undesirable.
Your only other option would be to work with your carrier to get a custom redirect, which is built into the CO switch (i.e. you never see the call in the HQ site). There is a monthly charge for this type of service (usually).
So, you can:
a. carry the RTP traffic on your WAN
b. hangup 2x the number of B-channels on your HQ gateway to facilitate the redirect
Thanks Williams. My situation is that gateway is in remote site.
That will be :
Based on your explanation, I think the RTP traffic will not flow through WAN, it only resides between remote gateway and remote phone in remote site. Right?
If I want to redirect the RTP traffic through the HQ gateway, I think the way is like you said: Get carrier forward the DID in remote site to DID in HQ. Then the RTP traffic will flow through HQ gateway and WAN to remote site phone.
If the DID is provisioned on trunks in your Remote-Gateway and the final destination is the Remote-Phone then the RTP will stay on your remote site LAN.
Basically, the RTP stream is not established until the call routing decision is made (which includes any forwarding information). Once the RTP stream is established it will be setup between the origination point on your network (e.g. Remote-Gateway) and the final called party (as opposed to the original called party which was a forwarded line).
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...