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: CCM Trace Questions | MediaMgr (Daniel Pagan)
2. Re: CCM Trace Questions | MediaMgr (Brian Meade (brmeade))
3. Re: CCM Trace Questions | MediaMgr (Ryan Ratliff (rratliff))
4. UCCE Outbound , any way to block calls? (0703Manjunath)
5. Re: SIP trunk putting call on hold drops call (Mark Holloway)
6. Re: UCCE Outbound , any way to block calls? (Tim Smith)
7. Re: SIP trunk putting call on hold drops call (Jason Aarons (AM))
8. Migrating from CUCM 7.1 & Unity to BE6000 (Robin Clayton)
9. Licence Migration 7.1 top 9.x (Robin Clayton)
10. Re: Licence Migration 7.1 top 9.x (Andy)
----------------------------------------------------------------------
Message: 1
Date: Mon, 21 Oct 2013 16:04:27 +0000
From: Daniel Pagan <[email protected]>
To: "Ryan Ratliff (rratliff)" <[email protected]>, "Brian Meade
(brmeade)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] CCM Trace Questions | MediaMgr
Message-ID:
<a4f4beead515f947ac82d086a78c70f6603b3...@nyc-exch-mb01.fidelus.com>
Content-Type: text/plain; charset="iso-8859-1"
One last question on this thread... Can you tell me the significance of the 3rd
and 4th numeric values following a process name on SDLSig lines? The fourth
value seems like the unique process ID number but I haven't been able to
correlate the 3rd value with anything significant yet.
Also... If you cant disclose this information then I understand, but I'm also
curious about the Cdcc and Cc processes. I often see the Cc and Cdcc processes
involved in CTI line events. Are these two responsible for interfacing with
media processes?
Thanks again
Daniel
From: Ryan Ratliff (rratliff) [mailto:[email protected]]
Sent: Tuesday, October 15, 2013 3:45 PM
To: Brian Meade (brmeade)
Cc: Daniel Pagan; [email protected]
Subject: Re: [cisco-voip] CCM Trace Questions | MediaMgr
Specific to MGCP you'll see delays there because even though the gateway
generates an SDP in the Ack to the CRCX we don't use that info until media is
established for the call.
To dumb this excellent discussion down a bit MediaManager is created when media
negotiation has to happen between two call legs and this doesn't always happen
at the same time one leg sends its media information.
The MXTimeout getting cancelled will be whenever we need to stop waiting for
the media connection to be established. In general this happens when we have
enough information from both call legs to proceed with establishing media or
cancel the call because there are no matching capabilities. It can also happen
if one side disconnects the call during media negotiation (try H.323 over a
satellite with slow-start and you'll see this a lot).
-Ryan
On Oct 15, 2013, at 2:11 PM, Brian Meade (brmeade)
<[email protected]<mailto:[email protected]>> wrote:
To further expand on this from what I found, a new MediaManager process is
created any time there is an AuConnectRequest unless the call was early offer
in which this would have already been created. AuConnectRequest is triggered
by ConnPartyReq received by MatrixControl which seems to handle the logic of
when to send the AuConnectRequest. There's many, many reasons why one is made
and one isn't and I can't just share every potential scenario but my previous
comment should cover most of it.
From: Brian Meade (brmeade)
Sent: Tuesday, October 15, 2013 1:35 PM
To: 'Daniel Pagan';
[email protected]<mailto:[email protected]>
Subject: RE: CCM Trace Questions | MediaMgr
Daniel,
My understanding trying to not directly copy&paste CUCM source code is that a
MediaManager process is created whenever an Media Offer is received that needs
a corresponding Media Answer. In the case of Prack being disabled, an answer
wouldn't be necessary so we don't need to create a new MediaManager process for
this.
Still going through the code to see when the MXTimeout timer is turned off.
The problem is it's in a subroutine that gets called in a lot of different
scenarios. I'm trying to find a corresponding trace line that would print in a
few of the scenarios.
Brian
From: Daniel Pagan [mailto:[email protected]]
Sent: Tuesday, October 15, 2013 1:31 PM
To: Brian Meade (brmeade);
[email protected]<mailto:[email protected]>
Subject: RE: CCM Trace Questions | MediaMgr
Brian:
Thanks for the answer.
Another question on MediaManager... Is a new MediaManager process created when
very specific events are witnessed by CUCM? I guess another way to ask this
would be, is it safe to say the creation of a new MediaManager process is
initiated by specific events during the call, received by the outbound
call-leg, and vary from protocol to protocol? I'm aware it's during the media
connection attempt for two CIs, but I'm hoping to get some more detailed
information.
Here's an example of what I'm referring to... Audio cut through (MediaMgr
creation) occurs for outbound call-leg events such as:
CUCM <-- 183 w/ SDP
==PRACK is enabled==
==MediaMgr gets created, audio cut through is attempted==
CUCM --> PRACK w/ SDP
However, I don't see CUCM attempting audio cut through in the following
scenario:
CUCM <-- 183 w/ SDP
==PRACK is disabled==
==MediaMgr is not created==
..
...
CUCM <-- 200 w/ SDP eventually received
==MediaMgr gets created, audio cut through is attempted==
CUCM --> ACK w/ SDP
Because MediaManager is created between the Rx 183 and Tx PRACK, and I see no
creation after Rx 183 when PRACK is disabled, this makes me think that, at a
programming level, the creation of MediaManager is tied to very specific events
witnessed by CUCM combined with configurations on the called device. Something
like this (forgive me... I'm no programmer... just trying to lay out my
thoughts)
On the outbound leg, create new MediaMgr process and attempt media exchange:
IF (Received ISDN Msg = Progress){
Create new MediaManager Process
}
ELSE IF (Received SCCP Answer = True){
Create new MediaManager Process
}
ELSE IF (Received SIP Msg = 183 offer AND PRACK = enabled){
Create new MediaManager Process
}
ELSE Do nothing..
My apologies for the long winded email. Is this order of operations correct?
I'm pretty much thinking while typing and trying to understand how this process
is initiated by CUCM in a more detailed way than just "whenever it's time to
establish audio".
Serious thanks you again if you made it to the end of the email :)
Daniel
From: Brian Meade (brmeade) [mailto:[email protected]]
Sent: Tuesday, October 15, 2013 11:58 AM
To: Daniel Pagan; [email protected]<mailto:[email protected]>
Subject: RE: CCM Trace Questions | MediaMgr
Daniel,
For your second question, those capabilities are the equivalent SCCP
capabilities. Unfortunately, the SCCP codec mapping is technically Cisco
confidential so I can't share that table.
Working on getting an answer on your first question.
Thanks,
Brian Meade
From: cisco-voip [mailto:[email protected]] On Behalf Of
Daniel Pagan
Sent: Tuesday, October 15, 2013 11:16 AM
To: [email protected]<mailto:[email protected]>
Subject: [cisco-voip] CCM Trace Questions | MediaMgr
Hey Folks...
I have a few trace questions I'm hoping someone can help me with.
Is there a specific CCM trace entry that corresponds to the moment where the
Media Exchange Timeout timer is stopped? From what I understand, the timer
begins when a new MediaManager process is created for the AuConnect request,
but there doesn't seem to be any obvious moment when the timer is stopped
during a successful media connection. Would it be at the "AuConnectInfo, audio,
CI (xxxxxx, xxxxxx)"? The purpose of having this would be to quickly identify
the moment a successful media connection was established during situations
where reviewing signaling transactions for media capabilities isn't exactly
required.
With regards to MediaManager and its region capabilities pre-check, is there a
matrix or any document that provides the capability numbering to codec mapping?
I'm not referring to SDP dynamic payload mapping, but specifically the
"preCheckCapabilities" line in a CCM trace.
Thanks a lot ahead of time.
- Daniel
_______________________________________________
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/20131021/9a585183/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 21 Oct 2013 16:20:42 +0000
From: "Brian Meade (brmeade)" <[email protected]>
To: Daniel Pagan <[email protected]>, "Ryan Ratliff (rratliff)"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] CCM Trace Questions | MediaMgr
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Daniel,
It goes (node id, application id, process type, process instance).
Cdcc is Call-Dependent Call Control so this is a unique instance for a certain
call. Cc is call control and usually responsible for creating the Cdcc and
tracking the call state from what I've seen for the most part. I've never seen
either directly talk to media processes that I can recall.
Brian
From: Daniel Pagan [mailto:[email protected]]
Sent: Monday, October 21, 2013 12:04 PM
To: Ryan Ratliff (rratliff); Brian Meade (brmeade)
Cc: [email protected]
Subject: RE: [cisco-voip] CCM Trace Questions | MediaMgr
One last question on this thread... Can you tell me the significance of the 3rd
and 4th numeric values following a process name on SDLSig lines? The fourth
value seems like the unique process ID number but I haven't been able to
correlate the 3rd value with anything significant yet.
Also... If you cant disclose this information then I understand, but I'm also
curious about the Cdcc and Cc processes. I often see the Cc and Cdcc processes
involved in CTI line events. Are these two responsible for interfacing with
media processes?
Thanks again
Daniel
From: Ryan Ratliff (rratliff) [mailto:[email protected]]
Sent: Tuesday, October 15, 2013 3:45 PM
To: Brian Meade (brmeade)
Cc: Daniel Pagan; [email protected]<mailto:[email protected]>
Subject: Re: [cisco-voip] CCM Trace Questions | MediaMgr
Specific to MGCP you'll see delays there because even though the gateway
generates an SDP in the Ack to the CRCX we don't use that info until media is
established for the call.
To dumb this excellent discussion down a bit MediaManager is created when media
negotiation has to happen between two call legs and this doesn't always happen
at the same time one leg sends its media information.
The MXTimeout getting cancelled will be whenever we need to stop waiting for
the media connection to be established. In general this happens when we have
enough information from both call legs to proceed with establishing media or
cancel the call because there are no matching capabilities. It can also happen
if one side disconnects the call during media negotiation (try H.323 over a
satellite with slow-start and you'll see this a lot).
-Ryan
On Oct 15, 2013, at 2:11 PM, Brian Meade (brmeade)
<[email protected]<mailto:[email protected]>> wrote:
To further expand on this from what I found, a new MediaManager process is
created any time there is an AuConnectRequest unless the call was early offer
in which this would have already been created. AuConnectRequest is triggered
by ConnPartyReq received by MatrixControl which seems to handle the logic of
when to send the AuConnectRequest. There's many, many reasons why one is made
and one isn't and I can't just share every potential scenario but my previous
comment should cover most of it.
From: Brian Meade (brmeade)
Sent: Tuesday, October 15, 2013 1:35 PM
To: 'Daniel Pagan';
[email protected]<mailto:[email protected]>
Subject: RE: CCM Trace Questions | MediaMgr
Daniel,
My understanding trying to not directly copy&paste CUCM source code is that a
MediaManager process is created whenever an Media Offer is received that needs
a corresponding Media Answer. In the case of Prack being disabled, an answer
wouldn't be necessary so we don't need to create a new MediaManager process for
this.
Still going through the code to see when the MXTimeout timer is turned off.
The problem is it's in a subroutine that gets called in a lot of different
scenarios. I'm trying to find a corresponding trace line that would print in a
few of the scenarios.
Brian
From: Daniel Pagan [mailto:[email protected]]
Sent: Tuesday, October 15, 2013 1:31 PM
To: Brian Meade (brmeade);
[email protected]<mailto:[email protected]>
Subject: RE: CCM Trace Questions | MediaMgr
Brian:
Thanks for the answer.
Another question on MediaManager... Is a new MediaManager process created when
very specific events are witnessed by CUCM? I guess another way to ask this
would be, is it safe to say the creation of a new MediaManager process is
initiated by specific events during the call, received by the outbound
call-leg, and vary from protocol to protocol? I'm aware it's during the media
connection attempt for two CIs, but I'm hoping to get some more detailed
information.
Here's an example of what I'm referring to... Audio cut through (MediaMgr
creation) occurs for outbound call-leg events such as:
CUCM <-- 183 w/ SDP
==PRACK is enabled==
==MediaMgr gets created, audio cut through is attempted==
CUCM --> PRACK w/ SDP
However, I don't see CUCM attempting audio cut through in the following
scenario:
CUCM <-- 183 w/ SDP
==PRACK is disabled==
==MediaMgr is not created==
..
...
CUCM <-- 200 w/ SDP eventually received
==MediaMgr gets created, audio cut through is attempted==
CUCM --> ACK w/ SDP
Because MediaManager is created between the Rx 183 and Tx PRACK, and I see no
creation after Rx 183 when PRACK is disabled, this makes me think that, at a
programming level, the creation of MediaManager is tied to very specific events
witnessed by CUCM combined with configurations on the called device. Something
like this (forgive me... I'm no programmer... just trying to lay out my
thoughts)
On the outbound leg, create new MediaMgr process and attempt media exchange:
IF (Received ISDN Msg = Progress){
Create new MediaManager Process
}
ELSE IF (Received SCCP Answer = True){
Create new MediaManager Process
}
ELSE IF (Received SIP Msg = 183 offer AND PRACK = enabled){
Create new MediaManager Process
}
ELSE Do nothing..
My apologies for the long winded email. Is this order of operations correct?
I'm pretty much thinking while typing and trying to understand how this process
is initiated by CUCM in a more detailed way than just "whenever it's time to
establish audio".
Serious thanks you again if you made it to the end of the email :)
Daniel
From: Brian Meade (brmeade) [mailto:[email protected]]
Sent: Tuesday, October 15, 2013 11:58 AM
To: Daniel Pagan; [email protected]<mailto:[email protected]>
Subject: RE: CCM Trace Questions | MediaMgr
Daniel,
For your second question, those capabilities are the equivalent SCCP
capabilities. Unfortunately, the SCCP codec mapping is technically Cisco
confidential so I can't share that table.
Working on getting an answer on your first question.
Thanks,
Brian Meade
From: cisco-voip [mailto:[email protected]] On Behalf Of
Daniel Pagan
Sent: Tuesday, October 15, 2013 11:16 AM
To: [email protected]<mailto:[email protected]>
Subject: [cisco-voip] CCM Trace Questions | MediaMgr
Hey Folks...
I have a few trace questions I'm hoping someone can help me with.
Is there a specific CCM trace entry that corresponds to the moment where the
Media Exchange Timeout timer is stopped? From what I understand, the timer
begins when a new MediaManager process is created for the AuConnect request,
but there doesn't seem to be any obvious moment when the timer is stopped
during a successful media connection. Would it be at the "AuConnectInfo, audio,
CI (xxxxxx, xxxxxx)"? The purpose of having this would be to quickly identify
the moment a successful media connection was established during situations
where reviewing signaling transactions for media capabilities isn't exactly
required.
With regards to MediaManager and its region capabilities pre-check, is there a
matrix or any document that provides the capability numbering to codec mapping?
I'm not referring to SDP dynamic payload mapping, but specifically the
"preCheckCapabilities" line in a CCM trace.
Thanks a lot ahead of time.
- Daniel
_______________________________________________
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/20131021/4e58dd5f/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 21 Oct 2013 16:26:32 +0000
From: "Ryan Ratliff (rratliff)" <[email protected]>
To: Daniel Pagan <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] CCM Trace Questions | MediaMgr
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"
Cc = Call Control (only one of these per node)
Cdcc = Child of Call Control (one of these per call)
Here's the full break-down for Google purposes.
Cdcc(1,100,212,1311436)
1 - Node id
100 - App id
212 - process id
1311436 - process instance
On process id, some processes can have a range here, some will always be the
same.
Individually the 3rd isn't very useful. The 4th can tell you how busy a system
generally is since process ids typically increment.
What you really care about is the full set since together they identify a
specific process and let you follow everything into, out from, and (as of 9.x)
what happens in between.
-Ryan
On Oct 21, 2013, at 12:04 PM, Daniel Pagan
<[email protected]<mailto:[email protected]>>
wrote:
One last question on this thread? Can you tell me the significance of the 3rd
and 4th numeric values following a process name on SDLSig lines? The fourth
value seems like the unique process ID number but I haven?t been able to
correlate the 3rd value with anything significant yet.
Also? If you cant disclose this information then I understand, but I?m also
curious about the Cdcc and Cc processes. I often see the Cc and Cdcc processes
involved in CTI line events. Are these two responsible for interfacing with
media processes?
Thanks again
Daniel
From: Ryan Ratliff (rratliff) [mailto:[email protected]<http://cisco.com>]
Sent: Tuesday, October 15, 2013 3:45 PM
To: Brian Meade (brmeade)
Cc: Daniel Pagan; [email protected]<mailto:[email protected]>
Subject: Re: [cisco-voip] CCM Trace Questions | MediaMgr
Specific to MGCP you'll see delays there because even though the gateway
generates an SDP in the Ack to the CRCX we don't use that info until media is
established for the call.
To dumb this excellent discussion down a bit MediaManager is created when media
negotiation has to happen between two call legs and this doesn't always happen
at the same time one leg sends its media information.
The MXTimeout getting cancelled will be whenever we need to stop waiting for
the media connection to be established. In general this happens when we have
enough information from both call legs to proceed with establishing media or
cancel the call because there are no matching capabilities. It can also happen
if one side disconnects the call during media negotiation (try H.323 over a
satellite with slow-start and you'll see this a lot).
-Ryan
On Oct 15, 2013, at 2:11 PM, Brian Meade (brmeade)
<[email protected]<mailto:[email protected]>> wrote:
To further expand on this from what I found, a new MediaManager process is
created any time there is an AuConnectRequest unless the call was early offer
in which this would have already been created. AuConnectRequest is triggered
by ConnPartyReq received by MatrixControl which seems to handle the logic of
when to send the AuConnectRequest. There?s many, many reasons why one is made
and one isn?t and I can?t just share every potential scenario but my previous
comment should cover most of it.
From: Brian Meade (brmeade)
Sent: Tuesday, October 15, 2013 1:35 PM
To: 'Daniel Pagan';
[email protected]<mailto:[email protected]>
Subject: RE: CCM Trace Questions | MediaMgr
Daniel,
My understanding trying to not directly copy&paste CUCM source code is that a
MediaManager process is created whenever an Media Offer is received that needs
a corresponding Media Answer. In the case of Prack being disabled, an answer
wouldn?t be necessary so we don?t need to create a new MediaManager process for
this.
Still going through the code to see when the MXTimeout timer is turned off.
The problem is it?s in a subroutine that gets called in a lot of different
scenarios. I?m trying to find a corresponding trace line that would print in a
few of the scenarios.
Brian
From: Daniel Pagan [mailto:[email protected]]
Sent: Tuesday, October 15, 2013 1:31 PM
To: Brian Meade (brmeade);
[email protected]<mailto:[email protected]>
Subject: RE: CCM Trace Questions | MediaMgr
Brian:
Thanks for the answer.
Another question on MediaManager? Is a new MediaManager process created when
very specific events are witnessed by CUCM? I guess another way to ask this
would be, is it safe to say the creation of a new MediaManager process is
initiated by specific events during the call, received by the outbound
call-leg, and vary from protocol to protocol? I?m aware it?s during the media
connection attempt for two CIs, but I?m hoping to get some more detailed
information.
Here?s an example of what I?m referring to? Audio cut through (MediaMgr
creation) occurs for outbound call-leg events such as:
CUCM <-- 183 w/ SDP
==PRACK is enabled==
==MediaMgr gets created, audio cut through is attempted==
CUCM --> PRACK w/ SDP
However, I don?t see CUCM attempting audio cut through in the following
scenario:
CUCM <-- 183 w/ SDP
==PRACK is disabled==
==MediaMgr is not created==
..
?
CUCM <-- 200 w/ SDP eventually received
==MediaMgr gets created, audio cut through is attempted==
CUCM --> ACK w/ SDP
Because MediaManager is created between the Rx 183 and Tx PRACK, and I see no
creation after Rx 183 when PRACK is disabled, this makes me think that, at a
programming level, the creation of MediaManager is tied to very specific events
witnessed by CUCM combined with configurations on the called device. Something
like this (forgive me? I?m no programmer? just trying to lay out my thoughts)
On the outbound leg, create new MediaMgr process and attempt media exchange:
IF (Received ISDN Msg = Progress){
Create new MediaManager Process
}
ELSE IF (Received SCCP Answer = True){
Create new MediaManager Process
}
ELSE IF (Received SIP Msg = 183 offer AND PRACK = enabled){
Create new MediaManager Process
}
ELSE Do nothing..
My apologies for the long winded email. Is this order of operations correct?
I?m pretty much thinking while typing and trying to understand how this process
is initiated by CUCM in a more detailed way than just ?whenever it?s time to
establish audio?.
Serious thanks you again if you made it to the end of the email :)
Daniel
From: Brian Meade (brmeade) [mailto:[email protected]]
Sent: Tuesday, October 15, 2013 11:58 AM
To: Daniel Pagan; [email protected]<mailto:[email protected]>
Subject: RE: CCM Trace Questions | MediaMgr
Daniel,
For your second question, those capabilities are the equivalent SCCP
capabilities. Unfortunately, the SCCP codec mapping is technically Cisco
confidential so I can?t share that table.
Working on getting an answer on your first question.
Thanks,
Brian Meade
From: cisco-voip [mailto:[email protected]] On Behalf Of
Daniel Pagan
Sent: Tuesday, October 15, 2013 11:16 AM
To: [email protected]<mailto:[email protected]>
Subject: [cisco-voip] CCM Trace Questions | MediaMgr
Hey Folks?
I have a few trace questions I?m hoping someone can help me with.
Is there a specific CCM trace entry that corresponds to the moment where the
Media Exchange Timeout timer is stopped? From what I understand, the timer
begins when a new MediaManager process is created for the AuConnect request,
but there doesn?t seem to be any obvious moment when the timer is stopped
during a successful media connection. Would it be at the ?AuConnectInfo, audio,
CI (xxxxxx, xxxxxx)?? The purpose of having this would be to quickly identify
the moment a successful media connection was established during situations
where reviewing signaling transactions for media capabilities isn?t exactly
required.
With regards to MediaManager and its region capabilities pre-check, is there a
matrix or any document that provides the capability numbering to codec mapping?
I?m not referring to SDP dynamic payload mapping, but specifically the
?preCheckCapabilities? line in a CCM trace.
Thanks a lot ahead of time.
- Daniel
_______________________________________________
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/20131021/e00afb4a/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 22 Oct 2013 00:58:04 +0530
From: 0703Manjunath <[email protected]>
To: [email protected]
Subject: [cisco-voip] UCCE Outbound , any way to block calls?
Message-ID:
<cajjqyqt_fec+oqv5tb3qk0j3uv+mu6kzltrcctq9am2va0f...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
We have a requirement from a client on outbound contact centre(in agent
based campaign) that agents should not be able to make any outbound calls
, not even between extension .
It was easy for blocking pstn calls but not aware on how to block the calls
between extension.... any thoughts much appreciated
UCCE: 9.0.1
CM : 9.x
--
Thanks & Regards
Manjunath
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20131022/920ba475/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 21 Oct 2013 09:09:06 -0400
From: Mark Holloway <[email protected]>
To: Mike <[email protected]>
Cc: 'Cisco VOIP' <[email protected]>
Subject: Re: [cisco-voip] SIP trunk putting call on hold drops call
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
A SIP Wireshark capture would be helpful both with and without the MTP enabled.
On Oct 20, 2013, at 9:37 PM, Mike <[email protected]> wrote:
> I have a SIP trunk from Windstream where if I put the call on hold it drops
> the call. If I check MTP required it works fine. I have a transcoder and IOS
> software MTP configured and in the MRGL on the Trunk config.
>
> Any ideas?
>
> Thanks,
> Mike
> _______________________________________________
> 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/20131021/c3a6da36/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 21 Oct 2013 20:33:47 +0000
From: Tim Smith <[email protected]>
To: 0703Manjunath <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] UCCE Outbound , any way to block calls?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hey mate,
You have multiple ways to do this.
Give the phones and lines an empty CSS. Ensure you do not have any numbers in
the system in no or none partition. That will stop everything.
You could add back in partitions if there were any internal route points that
needed to be reached.
You would need to be careful that none of your call flows required any calls
made from the phone - I.e transfer to supervisor for example
I assume your phone doesn't make an outbound call, rather UCCE makes the call
to contact, then makes another call to agent and just connects the two legs?
You could also build translation patterns to block specific patterns I.e
internal extensions, and therefore allow others.
Either way may require some reorganisation of your dial plan / partitions.
Cheers,
Tim
> On 22 Oct 2013, at 6:59 am, "0703Manjunath" <[email protected]> wrote:
>
> We have a requirement from a client on outbound contact centre(in agent based
> campaign) that agents should not be able to make any outbound calls , not
> even between extension .
>
> It was easy for blocking pstn calls but not aware on how to block the calls
> between extension.... any thoughts much appreciated
>
> UCCE: 9.0.1
> CM : 9.x
> --
> Thanks & Regards
> Manjunath
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
Message: 7
Date: Mon, 21 Oct 2013 18:49:30 -0400
From: "Jason Aarons (AM)" <[email protected]>
To: Mark Holloway <[email protected]>, Mike <[email protected]>
Cc: 'Cisco VOIP' <[email protected]>
Subject: Re: [cisco-voip] SIP trunk putting call on hold drops call
Message-ID:
<4e38db0a1959b04c8c83edcf069b53ed0d3bec7...@usispclexdb01.na.didata.local>
Content-Type: text/plain; charset="windows-1252"
Consider the Advanced Service parameter Full Duplex.
http://marc.info/?l=cisco-voip&m=134625159201713
From: cisco-voip [mailto:[email protected]] On Behalf Of Mark
Holloway
Sent: Monday, October 21, 2013 9:09 AM
To: Mike
Cc: 'Cisco VOIP'
Subject: Re: [cisco-voip] SIP trunk putting call on hold drops call
A SIP Wireshark capture would be helpful both with and without the MTP enabled.
On Oct 20, 2013, at 9:37 PM, Mike <[email protected]<mailto:[email protected]>> wrote:
I have a SIP trunk from Windstream where if I put the call on hold it drops
the call. If I check MTP required it works fine. I have a transcoder and IOS
software MTP configured and in the MRGL on the Trunk config.
Any ideas?
Thanks,
Mike
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20131021/300ea52a/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 22 Oct 2013 14:43:23 +0000
From: Robin Clayton <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] Migrating from CUCM 7.1 & Unity to BE6000
Message-ID:
<883574BD6A83B04EAA11A5B54F4DFFE3C6DED8@SV-C-EXCHMB-01.richardrose.internal>
Content-Type: text/plain; charset="us-ascii"
Dear All.
CUCM 7.1.x
Unity 7.1.x
Is there a guide on migrating these to a BE6000 server retaining the
configuration?
I looked but I could not find a guide.
Is there any advantage of the BE6000 over a UCS with CUCM and Unity installed
on it?
The environment only require less than 200 phones.
Cheers
Rob
Robin Clayton
Senior I.T. Technician
Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
CA1 1LY
--------------------------------------------------------------------------------------------------------------
Important Notice:
This e-mail and any attachment are confidentialand may be privileged
or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.
The Richard Rose Federation<http://www.rrfa.org.uk>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20131022/f5bc638e/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 22 Oct 2013 14:51:13 +0000
From: Robin Clayton <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] Licence Migration 7.1 top 9.x
Message-ID:
<883574BD6A83B04EAA11A5B54F4DFFE3C6DEFA@SV-C-EXCHMB-01.richardrose.internal>
Content-Type: text/plain; charset="us-ascii"
Dear all.
Is there a need to update licences when moving from 7.1 to 9.1
I guess if we virtualise then we need to get updated licences.
Cheers
Rob
Robin Clayton
Senior I.T. Technician
Richard Rose Federation
Richard Rose Central Academy
Victoria Place
Carlisle
CA1 1LY
--------------------------------------------------------------------------------------------------------------
Important Notice:
This e-mail and any attachment are confidentialand may be privileged
or otherwise protected from disclosure. It is solely intended for the
person(s) named above. If you are not the intended recipient, any
reading, use, disclosure, copying or distribution of all or parts of this
e-mail or associated attachments is strictly prohibited. If you are not
an intended recipient, please notify the sender immediately by
replying to this message or by telephone and delete this e-mail and
any attachments permanently from your system.
The Richard Rose Federation<http://www.rrfa.org.uk>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20131022/a160c355/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 22 Oct 2013 16:35:58 +0100
From: Andy <[email protected]>
To: Robin Clayton <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [cisco-voip] Licence Migration 7.1 top 9.x
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Robin,
The Drive to 9 promotion from Cisco might be a good start and yes you
will need to sort out the licenses as in V9 they are user based.
If there is wireless around there is an app for Ipad which will sort out
the licensing (or at least give you an idea of what is required.
https://itunes.apple.com/us/app/cucm-collaboration-central/id650114526?ls=1&mt=8
Regards
Andy
On 22/10/2013 15:51, Robin Clayton wrote:
>
> Dear all.
>
> Is there a need to update licences when moving from 7.1 to 9.1
>
> I guess if we virtualise then we need to get updated licences.
>
> Cheers
>
> Rob
>
> Robin Clayton
>
> Senior I.T. Technician
>
> Richard Rose Federation
>
> Richard Rose Central Academy
>
> Victoria Place
>
> Carlisle
>
> CA1 1LY
>
> --------------------------------------------------------------------------------------------------------------
>
> *Important Notice:*
>
> This e-mail and any attachment are confidentialand may be privileged
> or otherwise protected from disclosure. It is solely intended for the
> person(s) named above. If you are not the intended recipient, any
> reading, use, disclosure, copying or distribution of all or parts of this
> e-mail or associated attachments is strictly prohibited. If you are not
> an intended recipient, please notify the sender immediately by
> replying to this message or by telephone and delete this e-mail and
> any attachments permanently from your system.
>
> *The Richard Rose Federation <http://www.rrfa.org.uk>*
>
>
> _______________________________________________
> 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/20131022/8015c26c/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
End of cisco-voip Digest, Vol 120, Issue 21
*******************************************
