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: h323 Call Preserve and features (Wes Sisk (wsisk))
2. Re: h323 Call Preserve and features (Pawlowski, Adam)
3. CM v9 limiting call duration (khaled Saholy)
4. Re: CM v9 limiting call duration (khaled Saholy)
5. Unity Connection 9.1 Split brain (Mike )
6. Re: Unity Connection 9.1 Split brain (Chris Ward (chrward))
7. SNR/Mobility Not Working for Transferred Calls with User
Control (Matthew Loraditch)
----------------------------------------------------------------------
Message: 1
Date: Mon, 6 Jan 2014 18:18:23 +0000
From: "Wes Sisk (wsisk)" <[email protected]>
To: "Pawlowski, Adam" <[email protected]>
Cc: cisco-voip voyp list <[email protected]>
Subject: Re: [cisco-voip] h323 Call Preserve and features
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Inline, ws.
On Jan 6, 2014, at 11:23 AM, "Pawlowski, Adam"
<[email protected]<mailto:[email protected]>> wrote:
Yes, that?s exactly right, I just null routed the CUCM from the gateway itself,
I didn?t take the UCM down. I?d say bringing the UCM down is the more likely
failure scenario (reboot/patch/crash) than any such thing with the uplink from
the voice router, as that?s sufficiently diverse.
There seems to be a purposeful option to tell the UCM not to tear down the call
when the TCP control session dies off, that it could do something with that
information, though I?m not sure what.
ws: by enabling preservation and h225/h245 TCP keep alive UCM should identify
the h323 call control session is lost and update the phone status to "CM Down,
Features Disabled". I believe that text is customizable so perhaps someone has
changed it in your environment. That update would also disable supplementary
services such as hold and transfer. Note that that will only happen after TCP
keep alive timeout (after TCP max retransmits exceeded, and TCP ack timeout
expired). While those retries are in progress UCM is unaware the call control
session is lost so the phone stays in "normal" state with normal functionality.
Attempting hold/transfer will invoke h323 signaling which will also go through
TCP timeout and eventually fail. That is the nature of the transient state with
two "intelligent" endpoints.
Assuming that another UCM node cannot assume control of the call (I don?t know
enough of h323 to know if that?s possible) there?s probably not much to do.
ws: Correct, another UCM cannot assume control of that call. With MGCP the
gateway can report the DS0 status to the failover UCM so the secondary UCM can
assume management of the call on that DS0.
It would be nice if I were in a perfect world scenario, and I could configure
the dial-peers to route the calls to the UCM that holds the DN that belongs to
the phone that?s (normally) registered to it, so the phone would see the UCM
down message and the softkeys would clear. That?s not reasonable, though. At
least in this case, for planned maintenance I can shut down the dial-peer ahead
of time to allow for normal clearing and a higher preference peer to be used,
and then reload the UCM when it?s not going to cause this issue.
I?ll go play with SIP and see what that does for us, if anything different.
Thanks again for all the replies.
Adam P
SUNYAB
From: Ryan Ratliff (rratliff) [mailto:[email protected]<http://cisco.com>]
Sent: Saturday, January 04, 2014 4:30 PM
To: Brian Meade (brmeade)
Cc: Erick Bergquist; Pawlowski, Adam; cisco-voip voyp list
Subject: Re: [cisco-voip] h323 Call Preserve and features
I believe what he was doing was breaking the routing between the gateway and
CUCM, not the phone and CUCM.
As has been noted already I'd agree that the goal for any preserved call is for
media to stay up. Ideally if the ccm service can detect the signaling
connection to the peer is down it can notify the endpoint(s) that the call has
been preserved (so they can disable features). In this case the call is going
great until the endpoint tries to do something that will use the signaling
channel (ie hold). This is going to cause CUCM to try an send an empty TCS to
the gateway, which of course will fail. Absent special handling for the
preserved call this media exchange will fail, triggering the hold to fail, and
thus the call. If TCP keepalives are enabled for both H.225 and H.245 then
there's at least a chance ccm and the gateway can preserve the call, otherwise
there won't be any packets sent on either TCP session and thus no way for
either side to even know the connection is down until it's too late.
The only protocol I'm aware of now that will actually tell the phone when a
call is preserved because the remote gateway is unregistered is MGCP, though
for the life of me I can't remember the exact error message that shows on the
phone. Whether this same message will show up for a preserved SIP or H.323
call is a very good question, and a good enhancement if it's not.
-Ryan
On Jan 3, 2014, at 5:26 PM, Brian Meade (brmeade)
<[email protected]<mailto:[email protected]>> wrote:
If he?s not seeing this, it may be due to him null routing the node the H.323
signaling is using but not the node the phone is registered to. Off the top of
my head, I don?t think the phone will be alerted in a scenario like that. In
order to make sure the users get the CM Down message, I?d make sure to use the
same primary node for incoming/outgoing H.323 signaling as the IP Phones are
using.
Brian
From: Erick Bergquist [mailto:[email protected]]
Sent: Friday, January 03, 2014 5:14 PM
To: Pawlowski, Adam
Cc: Brian Meade (brmeade);
[email protected]<mailto:[email protected]>
Subject: Re: [cisco-voip] FW: h323 Call Preserve and features
I believe the phone should also say "CM down Features disabled" when the phone
is up on a call still but loses connectivity to call manager if things are
working correct. Are you seeing that on the phone display at all?
On Fri, Jan 3, 2014 at 3:57 PM, Pawlowski, Adam
<[email protected]<mailto:[email protected]>> wrote:
Brian, Wes,
Thanks ! With that in mind it does seem to work. If it's a connectivity
thing, and the UCM becomes reachable within a reasonable time frame, call
control capabilities eventually resume, but it's not immediate and you would
not know anyways from the end station. With that in mind, I was able to
successfully set up preferenced dial peers and a couple of translation rules,
so that calls to a targeted number will re-route back out to the PSTN to an
alternate destination if the UCMs are not available, but the calls in progress
stay alive. The rest of the calls get network failure and I get re-order or
such from their local switch, so their clear off the PRI. While not as
convenient to set up and operate, if the only goal is to shorten failure times,
and provide for q931 through UCM loss, this does beat out MGCP. I have not
evaluated other caveats of MGCP or de-centralizing our dial-plan control, but
at least I know how this works now.
Thanks again all
Adam P
> -----Original Message-----
> From: Brian Meade (brmeade)
> [mailto:[email protected]<mailto:[email protected]>]
> Sent: Friday, January 03, 2014 4:35 PM
> To: Pawlowski, Adam;
> [email protected]<mailto:[email protected]>
> Subject: RE: [cisco-voip] FW: h323 Call Preserve and features
>
> Adam,
>
> You're correct in that we're really only going to keep the media up and keep
> the call connected in a call preservation scenario. Any extended features
> such as hold/resume/transfer will have very strange behavior with the
> signaling channel being down. In a call preservation scenario, both sides
> have
> to disconnect the call due to the signaling being down as well.
>
> Another thing to check with H.323 call preservation is what you have the
> "Allow Peer to Preserve H.323 Calls" CallManager service parameter set to as
> this is "False" by default.
>
> Brian
>
> -----Original Message-----
> From: cisco-voip
> [mailto:[email protected]<mailto:[email protected]>]
> On Behalf Of
> Pawlowski, Adam
> Sent: Friday, January 03, 2014 4:16 PM
> To: [email protected]<mailto:[email protected]>
> Subject: [cisco-voip] FW: h323 Call Preserve and features
>
>
> I have now set "Accept Unknown TCP Connection" to true, and "Allow TCP
> KeepAlives for H323" was left on true. I tried it on false, and it seems to
> have
> the same behavior - media is preserved between endpoints for some period
> of time (I did not wait excessively to see if it changes). Initially, soft
> functions
> (hold, transfer) do not work. After some period of time I can press "hold" to
> envoke hold, and I hear the hold tone, but resume does not work, and the
> call clears from the phone. From the remote station, I continue to hear the
> hold tone until the call drops off fast busy.
>
> I have "call preserve" configured for the h323 voice class. I'm not really
> sure
> there are other options - I believe the goal for this sort of thing is to
> allow
> media to survive until connectivity to the same UCM is re-established, it is
> not capable of allowing call control to migrate to another node in the
> cluster.
> I'm not sure if that's correct or not, as to what it does.
>
> Adam P
> SUNYAB
>
>
> > > -----Original Message-----
> > > From: Wes Sisk (wsisk) [mailto:[email protected]<mailto:[email protected]>]
> > > Sent: Friday, January 03, 2014 2:14 PM
> > > To: Pawlowski, Adam
> > > Cc: [email protected]<mailto:[email protected]>
> > > Subject: Re: [cisco-voip] h323 Call Preserve and features
> > >
> > > UCM has to know the h225 call control session is lost to properly
> > > invoke
> > call
> > > preservation. The network has to fail in a way that allows this or
> > > UCM has
> > to
> > > detect TCP session failure via keep alive timeout. That would be via
> > > h225
> > TCP
> > > keepalives. Verify they are enabled:
> > >
> > > Service Parameter:
> > >
> > > Accept Unknown TCP Connection: This parameter specifies the valid
> > > value as True or False. If the parameter is set to True, the system
> > accepts
> > > incoming TCP connection even when corresponding H323 gateway or
> > > trunk profile is not found at the time of TCP connection
> > > establishment;
> > otherwise,
> > > the system rejects TCP connection.
> > > This is a required field.
> > > Default: False
> > > Allow TCP KeepAlives For H323: This parameter determines whether
> > > Cisco CallManager sends KeepAlive messages to the H.323 device. When
> > > IP connectivity between the originating voice gateway (which is
> > > registered to Cisco CallManager as an H.323 endpoint) and Cisco
> > > CallManager is lost,
> > Cisco
> > > CallManager does not send a disconnect message to the terminating
> > > voice gateway after TCP KeepAlive timeout. This results in calls
> > > being
> > disconnected
> > > on the originating side only and a blocked connection between Cisco
> > > CallManager and the terminating gateway. When this parameter is set
> > > to True, the terminating H.323 endpoint can clear a blocked
> > > connection on a
> > TCP
> > > timeout. Valid values specify True (enable TCP KeepAlives for H.323)
> > > or
> > False
> > > (disable KeepAlives). NOTE: Changing this parameter value affects
> > > outbound calls immediately; you must restart the Cisco CallManager
> > > service for the parameter change to take effect for inbound calls.
> > > This is a required field.
> > > Default: True
> > >
> > > -Wes
> > >
> > >
> > > On Jan 3, 2014, at 8:45 AM, "Pawlowski, Adam"
> > > <[email protected]<mailto:[email protected]>>
> > wrote:
> > >
> > > I've been working with our PRI IOS gateways a bit, trying to improve
> > > on MGCP's resilience in regard to service when the CUCM is down or
> > > transitioning. We service a non-PSAP police department on our
> > > campus, and they've asked the world of us in regard to never losing
> > > a call. I don't
> > think this
> > > is possible, but, we've demonstrated to them how MGCP works, and
> > > they're not satisfied. Presently, we have MGCP with 3 cucm nodes and
> > > the shut- backhaul-interfaces command enabled. Calls will overflow
> > > to our other
> > trunk
> > > group at another loc if the Ds are down here. The telco has not been
> > > reasonable about establishing any other extended services (network
> > > call redirect, DTO) to make that situation better, so while MGCP is
> > > failing
> > over
> > > due to WAN/CUCM outage, calls are not terminated and die off.
> > >
> > > I have set a test gateway up with H323, which works (save for 5ESS
> > > Fac IE CNAM which is fine), and have set up call preservation. Media
> > > stays up
> > when
> > > I null route one CUCM or another, to simulate a CUCM reload or failure.
> > > However, there's no reflection of a loss of call control from the
> > > station
> > (SCCP
> > > 7965). If you attempt to invoke call hold or such, media ends, the
> > > call
> > does
> > > not get held, and the call dies in place on the set (both ends - the
> > remote call
> > > off the gateway hangs in limbo too). At one point I hit transfer on
> > > the
> > set and
> > > heard the hold tone when it opened a new call. Am I missing
> > > something in configuration that the control of the call is never
> > > re-established, or
> > does not
> > > seem to do so properly? Is this how this feature is intended to operate?
> > >
> > > Adam P
> > > SUNYAB
> > >
> > > _______________________________________________
> > > cisco-voip mailing list
> > > [email protected]<mailto:[email protected]>
> > > https://puck.nether.net/mailman/listinfo/cisco-voip
> > >
> >
> >
>
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]<mailto:[email protected]>
> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[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/20140106/a3b99c8c/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 6 Jan 2014 19:39:48 +0000
From: "Pawlowski, Adam" <[email protected]>
To: "Wes Sisk (wsisk)" <[email protected]>, "Pawlowski, Adam"
<[email protected]>
Cc: cisco-voip voyp list <[email protected]>
Subject: Re: [cisco-voip] h323 Call Preserve and features
Message-ID:
<aeb16c1bf994004e90a436c0cc62287f048...@mb-ls3.itorg.ad.buffalo.edu>
Content-Type: text/plain; charset="us-ascii"
Wes,
With those options set, the call is preserved, but nothing is reflected
on the phone. That's only with breaking the connection between the gateway and
the UCM. If I reload the UCM that the phone is registered to, it behaves as
expected. I did manage to get it to show "Temp Fail" at some point, but I
don't know why it did and cannot really repeat that behavior. If it's supposed
to do something in the call preserve state, it doesn't appear to be. This is
just in a lab, so I'm not sure this is critical, especially with H323.
Adam
From: Wes Sisk (wsisk) [mailto:[email protected]]
Sent: Monday, January 06, 2014 1:18 PM
To: Pawlowski, Adam
Cc: Ryan Ratliff (rratliff); Brian Meade (brmeade); cisco-voip voyp list
Subject: Re: [cisco-voip] h323 Call Preserve and features
Inline, ws.
On Jan 6, 2014, at 11:23 AM, "Pawlowski, Adam"
<[email protected]<mailto:[email protected]>> wrote:
Yes, that's exactly right, I just null routed the CUCM from the gateway itself,
I didn't take the UCM down. I'd say bringing the UCM down is the more likely
failure scenario (reboot/patch/crash) than any such thing with the uplink from
the voice router, as that's sufficiently diverse.
There seems to be a purposeful option to tell the UCM not to tear down the call
when the TCP control session dies off, that it could do something with that
information, though I'm not sure what.
ws: by enabling preservation and h225/h245 TCP keep alive UCM should identify
the h323 call control session is lost and update the phone status to "CM Down,
Features Disabled". I believe that text is customizable so perhaps someone has
changed it in your environment. That update would also disable supplementary
services such as hold and transfer. Note that that will only happen after TCP
keep alive timeout (after TCP max retransmits exceeded, and TCP ack timeout
expired). While those retries are in progress UCM is unaware the call control
session is lost so the phone stays in "normal" state with normal functionality.
Attempting hold/transfer will invoke h323 signaling which will also go through
TCP timeout and eventually fail. That is the nature of the transient state with
two "intelligent" endpoints.
Assuming that another UCM node cannot assume control of the call (I don't know
enough of h323 to know if that's possible) there's probably not much to do.
ws: Correct, another UCM cannot assume control of that call. With MGCP the
gateway can report the DS0 status to the failover UCM so the secondary UCM can
assume management of the call on that DS0.
It would be nice if I were in a perfect world scenario, and I could configure
the dial-peers to route the calls to the UCM that holds the DN that belongs to
the phone that's (normally) registered to it, so the phone would see the UCM
down message and the softkeys would clear. That's not reasonable, though. At
least in this case, for planned maintenance I can shut down the dial-peer ahead
of time to allow for normal clearing and a higher preference peer to be used,
and then reload the UCM when it's not going to cause this issue.
I'll go play with SIP and see what that does for us, if anything different.
Thanks again for all the replies.
Adam P
SUNYAB
From: Ryan Ratliff (rratliff) [mailto:[email protected]<http://cisco.com>]
Sent: Saturday, January 04, 2014 4:30 PM
To: Brian Meade (brmeade)
Cc: Erick Bergquist; Pawlowski, Adam; cisco-voip voyp list
Subject: Re: [cisco-voip] h323 Call Preserve and features
I believe what he was doing was breaking the routing between the gateway and
CUCM, not the phone and CUCM.
As has been noted already I'd agree that the goal for any preserved call is for
media to stay up. Ideally if the ccm service can detect the signaling
connection to the peer is down it can notify the endpoint(s) that the call has
been preserved (so they can disable features). In this case the call is going
great until the endpoint tries to do something that will use the signaling
channel (ie hold). This is going to cause CUCM to try an send an empty TCS to
the gateway, which of course will fail. Absent special handling for the
preserved call this media exchange will fail, triggering the hold to fail, and
thus the call. If TCP keepalives are enabled for both H.225 and H.245 then
there's at least a chance ccm and the gateway can preserve the call, otherwise
there won't be any packets sent on either TCP session and thus no way for
either side to even know the connection is down until it's too late.
The only protocol I'm aware of now that will actually tell the phone when a
call is preserved because the remote gateway is unregistered is MGCP, though
for the life of me I can't remember the exact error message that shows on the
phone. Whether this same message will show up for a preserved SIP or H.323
call is a very good question, and a good enhancement if it's not.
-Ryan
On Jan 3, 2014, at 5:26 PM, Brian Meade (brmeade)
<[email protected]<mailto:[email protected]>> wrote:
If he's not seeing this, it may be due to him null routing the node the H.323
signaling is using but not the node the phone is registered to. Off the top of
my head, I don't think the phone will be alerted in a scenario like that. In
order to make sure the users get the CM Down message, I'd make sure to use the
same primary node for incoming/outgoing H.323 signaling as the IP Phones are
using.
Brian
From: Erick Bergquist [mailto:[email protected]]
Sent: Friday, January 03, 2014 5:14 PM
To: Pawlowski, Adam
Cc: Brian Meade (brmeade);
[email protected]<mailto:[email protected]>
Subject: Re: [cisco-voip] FW: h323 Call Preserve and features
I believe the phone should also say "CM down Features disabled" when the phone
is up on a call still but loses connectivity to call manager if things are
working correct. Are you seeing that on the phone display at all?
On Fri, Jan 3, 2014 at 3:57 PM, Pawlowski, Adam
<[email protected]<mailto:[email protected]>> wrote:
Brian, Wes,
Thanks ! With that in mind it does seem to work. If it's a connectivity
thing, and the UCM becomes reachable within a reasonable time frame, call
control capabilities eventually resume, but it's not immediate and you would
not know anyways from the end station. With that in mind, I was able to
successfully set up preferenced dial peers and a couple of translation rules,
so that calls to a targeted number will re-route back out to the PSTN to an
alternate destination if the UCMs are not available, but the calls in progress
stay alive. The rest of the calls get network failure and I get re-order or
such from their local switch, so their clear off the PRI. While not as
convenient to set up and operate, if the only goal is to shorten failure times,
and provide for q931 through UCM loss, this does beat out MGCP. I have not
evaluated other caveats of MGCP or de-centralizing our dial-plan control, but
at least I know how this works now.
Thanks again all
Adam P
> -----Original Message-----
> From: Brian Meade (brmeade)
> [mailto:[email protected]<mailto:[email protected]>]
> Sent: Friday, January 03, 2014 4:35 PM
> To: Pawlowski, Adam;
> [email protected]<mailto:[email protected]>
> Subject: RE: [cisco-voip] FW: h323 Call Preserve and features
>
> Adam,
>
> You're correct in that we're really only going to keep the media up and keep
> the call connected in a call preservation scenario. Any extended features
> such as hold/resume/transfer will have very strange behavior with the
> signaling channel being down. In a call preservation scenario, both sides
> have
> to disconnect the call due to the signaling being down as well.
>
> Another thing to check with H.323 call preservation is what you have the
> "Allow Peer to Preserve H.323 Calls" CallManager service parameter set to as
> this is "False" by default.
>
> Brian
>
> -----Original Message-----
> From: cisco-voip
> [mailto:[email protected]<mailto:[email protected]>]
> On Behalf Of
> Pawlowski, Adam
> Sent: Friday, January 03, 2014 4:16 PM
> To: [email protected]<mailto:[email protected]>
> Subject: [cisco-voip] FW: h323 Call Preserve and features
>
>
> I have now set "Accept Unknown TCP Connection" to true, and "Allow TCP
> KeepAlives for H323" was left on true. I tried it on false, and it seems to
> have
> the same behavior - media is preserved between endpoints for some period
> of time (I did not wait excessively to see if it changes). Initially, soft
> functions
> (hold, transfer) do not work. After some period of time I can press "hold" to
> envoke hold, and I hear the hold tone, but resume does not work, and the
> call clears from the phone. From the remote station, I continue to hear the
> hold tone until the call drops off fast busy.
>
> I have "call preserve" configured for the h323 voice class. I'm not really
> sure
> there are other options - I believe the goal for this sort of thing is to
> allow
> media to survive until connectivity to the same UCM is re-established, it is
> not capable of allowing call control to migrate to another node in the
> cluster.
> I'm not sure if that's correct or not, as to what it does.
>
> Adam P
> SUNYAB
>
>
> > > -----Original Message-----
> > > From: Wes Sisk (wsisk) [mailto:[email protected]<mailto:[email protected]>]
> > > Sent: Friday, January 03, 2014 2:14 PM
> > > To: Pawlowski, Adam
> > > Cc: [email protected]<mailto:[email protected]>
> > > Subject: Re: [cisco-voip] h323 Call Preserve and features
> > >
> > > UCM has to know the h225 call control session is lost to properly
> > > invoke
> > call
> > > preservation. The network has to fail in a way that allows this or
> > > UCM has
> > to
> > > detect TCP session failure via keep alive timeout. That would be via
> > > h225
> > TCP
> > > keepalives. Verify they are enabled:
> > >
> > > Service Parameter:
> > >
> > > Accept Unknown TCP Connection: This parameter specifies the valid
> > > value as True or False. If the parameter is set to True, the system
> > accepts
> > > incoming TCP connection even when corresponding H323 gateway or
> > > trunk profile is not found at the time of TCP connection
> > > establishment;
> > otherwise,
> > > the system rejects TCP connection.
> > > This is a required field.
> > > Default: False
> > > Allow TCP KeepAlives For H323: This parameter determines whether
> > > Cisco CallManager sends KeepAlive messages to the H.323 device. When
> > > IP connectivity between the originating voice gateway (which is
> > > registered to Cisco CallManager as an H.323 endpoint) and Cisco
> > > CallManager is lost,
> > Cisco
> > > CallManager does not send a disconnect message to the terminating
> > > voice gateway after TCP KeepAlive timeout. This results in calls
> > > being
> > disconnected
> > > on the originating side only and a blocked connection between Cisco
> > > CallManager and the terminating gateway. When this parameter is set
> > > to True, the terminating H.323 endpoint can clear a blocked
> > > connection on a
> > TCP
> > > timeout. Valid values specify True (enable TCP KeepAlives for H.323)
> > > or
> > False
> > > (disable KeepAlives). NOTE: Changing this parameter value affects
> > > outbound calls immediately; you must restart the Cisco CallManager
> > > service for the parameter change to take effect for inbound calls.
> > > This is a required field.
> > > Default: True
> > >
> > > -Wes
> > >
> > >
> > > On Jan 3, 2014, at 8:45 AM, "Pawlowski, Adam"
> > > <[email protected]<mailto:[email protected]>>
> > wrote:
> > >
> > > I've been working with our PRI IOS gateways a bit, trying to improve
> > > on MGCP's resilience in regard to service when the CUCM is down or
> > > transitioning. We service a non-PSAP police department on our
> > > campus, and they've asked the world of us in regard to never losing
> > > a call. I don't
> > think this
> > > is possible, but, we've demonstrated to them how MGCP works, and
> > > they're not satisfied. Presently, we have MGCP with 3 cucm nodes and
> > > the shut- backhaul-interfaces command enabled. Calls will overflow
> > > to our other
> > trunk
> > > group at another loc if the Ds are down here. The telco has not been
> > > reasonable about establishing any other extended services (network
> > > call redirect, DTO) to make that situation better, so while MGCP is
> > > failing
> > over
> > > due to WAN/CUCM outage, calls are not terminated and die off.
> > >
> > > I have set a test gateway up with H323, which works (save for 5ESS
> > > Fac IE CNAM which is fine), and have set up call preservation. Media
> > > stays up
> > when
> > > I null route one CUCM or another, to simulate a CUCM reload or failure.
> > > However, there's no reflection of a loss of call control from the
> > > station
> > (SCCP
> > > 7965). If you attempt to invoke call hold or such, media ends, the
> > > call
> > does
> > > not get held, and the call dies in place on the set (both ends - the
> > remote call
> > > off the gateway hangs in limbo too). At one point I hit transfer on
> > > the
> > set and
> > > heard the hold tone when it opened a new call. Am I missing
> > > something in configuration that the control of the call is never
> > > re-established, or
> > does not
> > > seem to do so properly? Is this how this feature is intended to operate?
> > >
> > > Adam P
> > > SUNYAB
> > >
> > > _______________________________________________
> > > cisco-voip mailing list
> > > [email protected]<mailto:[email protected]>
> > > https://puck.nether.net/mailman/listinfo/cisco-voip
> > >
> >
> >
>
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]<mailto:[email protected]>
> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[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/20140106/7e99a299/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 7 Jan 2014 16:04:54 +0300
From: khaled Saholy <[email protected]>
To: cisco-voip voyp list <[email protected]>
Subject: [cisco-voip] CM v9 limiting call duration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="cp1256"
Hi All,
I just have a request from our customer about a feature exists in Legacy PABX
which is limiting call duration to a PSTN destination (for example, mobile
calls) to a specified time like 30 minutes or more or less according to the
customer needs.
I haven't come to a solution in CM 7 or 8 but if there's any idea about it in
these versions or the latest 9.x , I'll be thankful for that.
Waiting for your inputs.
Thanks and Regards.
Khaled Al-Saholy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20140107/1c4a17de/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 7 Jan 2014 16:34:19 +0300
From: khaled Saholy <[email protected]>
To: Matthew Collins <[email protected]>, cisco-voip voyp list
<[email protected]>
Subject: Re: [cisco-voip] CM v9 limiting call duration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="cp1256"
Hi Matthew,
Thanks for your reply.
If it's a service parameter, it'll be applied to all outgoing calls and not on
a specific route pattern. Is that right?
Have you or any one seen or tried a solution like this?
I'm looking for limiting duration of some calls.
Regards.
Khaled
From: [email protected]
To: [email protected]; [email protected]
Subject: RE: [cisco-voip] CM v9 limiting call duration
Date: Tue, 7 Jan 2014 13:20:05 +0000
Hi Khaled ,
Under service parameters, This is taken from v8 but I?m sure it was in version
5 and above
Maximum Call Duration Timer:
This parameter specifies the minutes that a call can remain active before Cisco
CallManager clears it. A value of zero disables the timer.
This is a required field.
Default: 720
Minimum: 0
Maximum: 35791
Unit: min
Regards
Matthew
From: cisco-voip [mailto:[email protected]]
On Behalf Of khaled Saholy
Sent: 07 January 2014 13:05
To: cisco-voip voyp list
Subject: [cisco-voip] CM v9 limiting call duration
Hi All,
I just have a request from our customer about a feature exists in Legacy PABX
which is limiting call duration to a PSTN destination (for example, mobile
calls) to a specified time like 30 minutes or more or less according to the
customer needs.
I haven't come to a solution in CM 7 or 8 but if there's any idea about it in
these versions or the latest 9.x , I'll be thankful for that.
Waiting for your inputs.
Thanks and Regards.
Khaled Al-Saholy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20140107/2238647f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 833 bytes
Desc: not available
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20140107/2238647f/attachment-0001.gif>
------------------------------
Message: 5
Date: Tue, 7 Jan 2014 09:32:15 -0500
From: "Mike " <[email protected]>
To: "'Cisco VOIP'" <[email protected]>
Subject: [cisco-voip] Unity Connection 9.1 Split brain
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Will Split Brain auto-recover? Mines been in SB for 3 days the pub is
working fine should I just reboot the sub?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20140107/b71f4b7e/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 7 Jan 2014 15:02:23 +0000
From: "Chris Ward (chrward)" <[email protected]>
To: "Mike " <[email protected]>, "'Cisco VOIP'"
<[email protected]>
Subject: Re: [cisco-voip] Unity Connection 9.1 Split brain
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Call TAC and have them check.
Split brain is the recovery process and should resolve to a normal state. When
the HA pair has been out of contact with each other, upon reconnecting, they
enter Split Brian Recovery (SBR) mode. They are essentially doing a line by
line comparison of the database and syncing information between them. If
information on the Pub and Sub continues to change during this process or if
communication between the pair continues to drop, SBR would either continue to
run until they are in sync or SBR may need to restart.
We have seen some cases where continually interrupting SBR can result in a hung
state. I would not reboot the sub until you talk to TAC and have them take a
look however, so that you don't make it worse if it is still actually
processing. Although 3 days does seem long for most cases, how many users and
ports is this deployment?
+Chris
TME - Unity Connection and MediaSense
From: cisco-voip [mailto:[email protected]] On Behalf Of Mike
Sent: Tuesday, January 07, 2014 9:32 AM
To: 'Cisco VOIP'
Subject: [cisco-voip] Unity Connection 9.1 Split brain
Will Split Brain auto-recover? Mines been in SB for 3 days the pub is working
fine should I just reboot the sub?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20140107/408f27de/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 7 Jan 2014 16:48:48 +0000
From: Matthew Loraditch <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] SNR/Mobility Not Working for Transferred Calls
with User Control
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
We are being told by TAC this doesn't work. The customer thinks it should and I
frankly agree. We are insisting they provide documentation to prove the
behavior is not a bug. They have referenced the SRND but I am not reading
anything where it says SNR only works with Timer Control. In fact the user
control section doesn't list any caveats except that DTMF relay must be working.
Anyone have any insight here? If it's a bug that's fine but there should be a
bug ID.
[cid:[email protected]]
Matthew G. Loraditch - CCNP-Voice, CCNA-R&S, CCDA
1965 Greenspring Drive
Timonium, MD 21093
direct voice. 443.541.1518
fax. 410.252.9284
Twitter<http://twitter.com/heliontech> |
Facebook<http://www.facebook.com/#!/pages/Helion/252157915296> |
Website<http://www.heliontechnologies.com/> | Email
Support<mailto:[email protected]?subject=Technical%20Support%20Request>
Support Phone. 410.252.8830
[cid:[email protected]]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20140107/31bbc1d4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 33011 bytes
Desc: image001.jpg
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20140107/31bbc1d4/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 10887 bytes
Desc: image002.png
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20140107/31bbc1d4/attachment-0001.png>
------------------------------
Subject: Digest Footer
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
End of cisco-voip Digest, Vol 123, Issue 6
******************************************
