Send cisco-voip mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-voip
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-voip digest..."
Today's Topics:
1. Re: recommendations for handing off sip trunks as pri for
legacy (Mike )
2. Re: recommendations for handing off sip trunks as pri for
legacy (Anthony Holloway)
3. Re: CUCM on 3rd party hardware (CPU question) (Ryan Ratliff)
4. Re: Outbound Call Routing Timers (Ryan Ratliff)
----------------------------------------------------------------------
Message: 1
Date: Sun, 31 Mar 2013 16:34:32 -0400
From: "Mike " <[email protected]>
To: "'chris'" <[email protected]>, <[email protected]>
Subject: Re: [cisco-voip] recommendations for handing off sip trunks
as pri for legacy
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Chris,
I've done this several times. You will need CUBE licenses and a multi-flex
T1 card (MFT), but you easily convert the SIP handoff to PRI.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of chris
Sent: Sunday, March 31, 2013 9:28 AM
To: [email protected]
Subject: [cisco-voip] recommendations for handing off sip trunks as pri for
legacy
We have recently acquired a new location which has a legacy analog pbx and a
carrier who was providing service as a PRI.
The carrier has now stated they will no longer be supporting PRI and are
recommending a switch to SIP trunks, which would be fine if they provided
adtran or similar to handle the conversion.
The carrier says they do not get involved in this situation and its up to
the customer, so we are left to fend for ourselves :)
This loction already has a 2851 with ipvoice, and I was thinking I should be
able to do everything I need with that?
Googling seems to turn up lots of configs which simply terminate local calls
to a physically connected PRI, when in actuality I want to do the inverse
and use the cisco to hand off a traditional PRI to the analog system.
Anyone gone down this path before? Have any config examples of what I
described that I can reference?
Also what type of linecard would I need to handoff the PRI? Does it need to
be a MFT T1 card or plain t1 dsu/csu?
thanks in advance
chris
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
Message: 2
Date: Sun, 31 Mar 2013 21:43:30 -0500
From: Anthony Holloway <[email protected]>
To: Mike <[email protected]>
Cc: Cisco VoIP Group <[email protected]>
Subject: Re: [cisco-voip] recommendations for handing off sip trunks
as pri for legacy
Message-ID:
<CACRCJOjb14o6=UzTAP-sE=s9w0nm-xu81qjd-yadvxqqtdv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Unless I missed part of your requirements, I don't see where you'll need a
CUBE license. You are not doing IP-to-IP call legs (E.g., SIP-to-SIP or
H323-to-SIP or H323-to-H323), but instead doing SIP-to-POTS.
The config is very simple, but just like configuring a PRI for PSTN
connectivity, you need to sync up your settings with the telco for SIP.
I.e., Call control ip address and port, proxy settings, expected diversion
header, authentication mechanisms, early offer, etc.
The complete SIP guide on a router can be found in the CVOICE book/course
material. I highly recommend you read this book.
http://www.amazon.com/Implementing-Unified-Communications-Foundation-Learning/dp/1587204193/ref=sr_1_1?ie=UTF8&qid=1364782855&sr=8-1&keywords=cvoice+642
Below are some of my personal notes on SIP on a voice gateway.
! SIP Gateway Configurations
! ==============================================================================
! SIP gateways have two things:
! 1. SIP-UA (Optionally the destination can be set at the DP level)
! 2. VoIP (SIP) Dial Peers
! To configure the SIP UA which contains:
! Authentication (Optional)
! SIP Servers (Registrar and Proxy)
sip-ua
! To specify a sip-server (you can also type this at the DP level)
! This is how you configure the SIP proxy you point at
sip-server ipv4:192.168.3.1:5060
!
! SIP VoIP Dial Peers have these two things:
! 1. Session Protocol defined as SIP
! 2. A session target pointing at the SIP UA
! The first thing you need to do is change the default call control protocol
! from H.323 to SIP, then you need to add a session target
dial-peer voice 10 voip
session protocol sipv2
session target ipv4:192.168.3.1:5060
! OR if you specified the server in the sip-ua section
session target sip-server
!
! SIP uses UDP for outbound signaling by default, but you can change it if you
! want to or if you have to (ITSP standard)
voice service voip
sip
session transport tcp
! Or if you want to UDP it
! session transport udp
!
! Or at the DP level
dial-peer voice 10 voip
session transport tcp
!
! To bind to a source address globally (only way)
voice service voip
sip
bind control source-interface Loopback0
bind media source-interface Loopback0
! Or bind both in a single command (think of this like a macro for
the above two commands)
! bind all source-interface Loopback0
!
! The only way you can tune SIP timers is in SIP-UA mode
sip-ua
! To cut the default timer in half for how long an INVITE is valid
timers expires 90000
!
! If you have an ISDN->SIP gateway, and you would like Calling Name display
voice service voip
signaling forward unconditional
!
inteface Serial0/0/0:23
isdn supp-service name calling
!
! If you wish to enable CLID privacy (aka blocking)
dial-peer voice 10 voip
clid strip pi-restrict
!
! If you wish to enable mapping the calling number into the display name field
voice service voip
clid substitute name
!
! DTMF will be inband with the audio stream unless you say otherwise
dial-peer voice 10 voip
! This will try to use SIP NOTIFY first, then RTP-NTE second and prevent
! any DTMF from ever being inserted into the voice stream
dtmf-relay sip-notify rtp-nte digit-drop
!
! Fax support is on by default and is cisco fax relay
! To change this to another type, you could
voice service voip
! This configures t38 followed by pass-through globally
fax protocol t38 fallback pass-through g711ulaw
! You could also disable ECM
fax-relay ecm disable
! Or even prevent SG3 faxing (downgrades to G3)
fax-relay sg3-to-g3
!
! By default the fax rate is "voice" which means "as fast a possible"
! If you wanted to slow it down, you have to do it at the DP level
dial-peer voice 10 voip
! This slows down the transmission to 14.4kbps
fax rate 14400
! If you want the dial-peer to take on the fax-relay config from global
fax-relay system
!
! Modem passthrough is a breakthrough
voice service voip
modem passthrough nse codec g711ulaw
!
! If you want a dial-peer to use the global settings you need to...
dial-peer voice 10 voip
modem passthrough system
!
! Modem relay is better, and will auto fallback to passthrough.
voice service voip
modem relay nse codec g711ulaw
!
! If you want a dial-peer to use the global settings...oh wait, they can't
dial-peer voice 10 voip
modem relay nse codec g711ulaw
!
! If you're looking to change the codec of a voip call, you can do it globally
! with the added benefit of having a prioritized list...
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
!
dial-peer voice 10 voip
voice-class codec 1
!
! Or directly on the dial-peer, but at the cost of only a single codec
dial-peer voice 10 voip
codec g711ulaw
!
! For CUBE, you can actually just tell the DP to pass whatever it was given
voice class codec 1
codec preference 1 transparent
codec preference 2 g711ulaw
codec preference 3 g729r8
!
dial-peer voice 10 voip
voice-class codec 1
!
! Verifying SIP
! ==============================================================================
! Verify that the SIP feature is UP
show sip-ua service ! SIP Service is up
! debug the SIP messages
debug ccsip messages
On Sun, Mar 31, 2013 at 3:34 PM, Mike <[email protected]> wrote:
> Chris,
>
> I've done this several times. You will need CUBE licenses and a multi-flex
> T1 card (MFT), but you easily convert the SIP handoff to PRI.
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of chris
> Sent: Sunday, March 31, 2013 9:28 AM
> To: [email protected]
> Subject: [cisco-voip] recommendations for handing off sip trunks as pri for
> legacy
>
> We have recently acquired a new location which has a legacy analog pbx and
> a
> carrier who was providing service as a PRI.
>
> The carrier has now stated they will no longer be supporting PRI and are
> recommending a switch to SIP trunks, which would be fine if they provided
> adtran or similar to handle the conversion.
>
> The carrier says they do not get involved in this situation and its up to
> the customer, so we are left to fend for ourselves :)
>
> This loction already has a 2851 with ipvoice, and I was thinking I should
> be
> able to do everything I need with that?
>
> Googling seems to turn up lots of configs which simply terminate local
> calls
> to a physically connected PRI, when in actuality I want to do the inverse
> and use the cisco to hand off a traditional PRI to the analog system.
>
> Anyone gone down this path before? Have any config examples of what I
> described that I can reference?
>
> Also what type of linecard would I need to handoff the PRI? Does it need to
> be a MFT T1 card or plain t1 dsu/csu?
>
> thanks in advance
> chris
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130331/70c619a6/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 1 Apr 2013 10:48:12 -0400
From: Ryan Ratliff <[email protected]>
To: "Madziarczyk, Jonathan" <[email protected]>
Cc: [email protected]
Subject: Re: [cisco-voip] CUCM on 3rd party hardware (CPU question)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
You can also post in the collab user group. I believe the PM that owns this
bit of policy is active there and would likely be able to give you a specific
reason why they came up with the speed they did for that processor.
http://www.cisco.com/en/US/products/ps6884/products_tech_note09186a0080bf23f5.shtml
is also an appropriate read here. You are solidly in the ?If it works, is it
allowed by the vendor?s support policy rules?? category, and need to be very
aware of the support implications that come with it.
You may be perfectly fine, but in the event you have any issues you need to be
aware of what's going to happen. This is a simple risk analysis, and you
should be comfortable with whatever decision you make now (and document it in
case you have to justify it at a later date). If you do proceed with this cpu
at least make a point to under-utilize your servers.
As an aside the 1000-user OVA is only for BE6K (and the TRCs it is based off +
standalone ELM). You can't and shouldn't use it outside of those situations.
Finally, don't rely on CPU reservations for justifying how much cpu a UC app
may need. We don't allow CPU oversubscription for a reason (so the app can get
the full core if need be), and any reservation an app may or may not set is for
minimum processing power. Things don't tend to fall apart in an idle server.
Where the processing really counts is under heavy load, which is most commonly
associated with some other unexpected event (failover, call loop, etc). That
isn't the time when you want to start seeing process cores because the system
can't keep up with the incoming rate of signals. Those types of cascading
failures are generally when exec's start calling each other, and everyone
starts talking about root cause, design assurance, etc.
-Ryan
On Mar 29, 2013, at 2:41 PM, "Madziarczyk, Jonathan" <[email protected]>
wrote:
Thanks Matthew,
Yeah, I?ll need to whitebox at some point, once I can get some media.
>From the CPU side, it?s almost $3k to upgrade a single server that isn?t even
>3 months old.
Ah well, I?ll try at the SE/AM level and see what I get.
Jon
From: Matthew Loraditch [mailto:[email protected]]
Sent: Thursday, March 28, 2013 3:50 PM
To: Madziarczyk, Jonathan; [email protected]
Subject: RE: CUCM on 3rd party hardware (CPU question)
Those specs are carved in proverbial stone. You can see in the not supported
column your scenario is specifically denied. While I believe you are right
about actual performance, the test teams only have so many resources and there
have to be some rules. I think it?s pretty fair as is right now, they only
thing they really care about any more is the CPU you can build a white box at
this point if you want. You still need enough RAM and such but no requirements
as to brand, speed, etc.
You can certainly talk to your AM and SE and provide the feedback, but I?m 99%
sure there is no such thing as a dispensation. Why don?t you just get new CPUs
if everything else is ok with your servers?
Matthew G. Loraditch ? CCNP-Voice, CCNA, CCDA
1965 Greenspring Drive
Timonium, MD 21093
voice. 410.252.8830
fax. 410.252.9284
Twitter | Facebook | Website | Email Support
From: [email protected]
[mailto:[email protected]] On Behalf Of Madziarczyk, Jonathan
Sent: Thursday, March 28, 2013 4:28 PM
To: [email protected]
Subject: [cisco-voip] CUCM on 3rd party hardware (CPU question)
So I?m trying to figure this one out. Maybe some Cisco gurus can chime in?
I started by going off of this
document:http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware#Processors_.2F_CPUs
My brand new Dells have Intel Xeon E5-2660s in them which qualifies, but
they?re running at 2.2GHz instead of the requested 2.5GHz.
However when I look at this:
http://docwiki.cisco.com/wiki/OVA_Template_Details_for_Unified_CM_Release_9.0
I see that both the 1000 and 2500 user servers are based off of the E5500
series chips which is significantly slower than my processors, as based on the
following: http://ark.intel.com/compare/37104,37096,64584
Technically, the 1000user server model doesn?t even qualify as a valid hardware
config based off of the first docuwiki link, and both models are using 4yr old
CPUs while I?m trying to use a <1yr old cpu that?s 2 generations ahead of
Cisco?s recommendations (2x threads, 2x cache, 2x bus speed, 2x memory
bandwidth, more memory channels, faster Max Turbo Freq, etc). And secondly the
reservation is only for 800MHz, which means if there?s any contention, having a
2.5GHz chip means nothing, right?
I get that Cisco is trying to pad their stats to eliminate any sort of a
hardware issue, but from my perspective using a brand new server I already own
vs. spending another $8k. Especially, when I believe existing will run even
better than the OVA requirements.
Obviously I want to be TAC supported on the software, do I need to ask for
special dispensation to run on existing hardware (would that even have a
chance)?
Thoughts?
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130401/4b0ca715/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 1 Apr 2013 10:50:23 -0400
From: Ryan Ratliff <[email protected]>
To: Dana Tong <[email protected]>
Cc: "[email protected] \([email protected]\)"
<[email protected]>
Subject: Re: [cisco-voip] Outbound Call Routing Timers
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
> PS have you guys seen the bug with Mobility and 9.1(1)a with +E.164 DNs? The
> mobility softkey doesn't work. Apparently fixed in an earlier ES but not til
> version 10 for a general release.
This is CSCud88503 if you hit it and need the ES. It will also appear in any
9.1(1)SU that posts.
-Ryan
On Mar 29, 2013, at 4:16 AM, Dana Tong <[email protected]> wrote:
Thanks guys,
T310 was the timer to change on the H323 gateway, however the real problem was
that I was not receiving Q931 progress and connect messages. I spoke to the guy
who looks after the other PBX and it looks like he's fixed something on his
side. I am now seeing progress and connect messages. I will dial the timers
back to default and test again on Tuesday morning.
Thanks all.
PS have you guys seen the bug with Mobility and 9.1(1)a with +E.164 DNs? The
mobility softkey doesn't work. Apparently fixed in an earlier ES but not til
version 10 for a general release.
Regards,
Dana Tong
On 29/03/2013, at 3:45 PM, "Erick B." <[email protected]> wrote:
> What issues are you experiencing?
>
> If the PRIs are working fine, and all channels are in use it could be the
> Stop Routing on User Busy flag or unallocated Number flag coming into play,
> or something else.
>
> Also, I had a client with a remote site that was having WAN troubles and Call
> Manager could not establish a TCP connection to the remote gateway most of
> the time so the calls went out the second gateway in the route group. The CM
> traces clearly showed the TCP connection failed to establish to the first
> gateway.
>
> As Wes said, look through the SDI and possibly SDL traces to find cause of
> your problem.
>
>
>
> On Thu, Mar 28, 2013 at 12:42 PM, Wes Sisk <[email protected]> wrote:
> There are several timers that could potentially be expiring and causing the
> hunting. Most are under h.323 or isdn/q931. Careful review of CM SDI and SDL
> traces will reveal the exact condition causing the hunting - it could be
> something other than a timer.
>
> -wes
>
> On Mar 27, 2013, at 9:43 PM, Dana Tong <[email protected]> wrote:
>
> Hi all,
>
> I have a H323 Gateway with PRI connections to multiple providers.
>
> I have a CUCM Route List with two route groups configured Top-down.
> I can see calls hunting to the first PRI and then hunting to the second PRI
> ok.
>
> What I would like to do is extend the timer of the call setup to the first
> PRI before it tries to route to the second PRI.
>
> Does anyone know what timer this is? Would it be in the UCM Service
> Parameters for ?clusterwide parameters ? H323??
>
> Cheers
> Dana
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130401/64289af1/attachment-0001.html>
------------------------------
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
End of cisco-voip Digest, Vol 114, Issue 1
******************************************
