|
Home > Archive > Voice over IP Cisco > December 2007 > Transfer issue dropping calls
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Transfer issue dropping calls
|
|
|
| Has anyone come across an issue before where when you press the
transfer button the call gets dropped, I have one user who claims that when
one particular cell phone number calls in and she tried to transfer she
loses the call.
This is on a 7960 Version: 7.2 (4.0)
CCM 4.1(3) sr3c
| |
| Jonathan Charles 2007-12-06, 1:12 pm |
| Is there an MRGL assigned to the device pool? Cuz you need an MTP to transfer...
Jonathan
On Dec 6, 2007 10:59 AM, Nick <csvoip@googlemail.com> wrote:
> Has anyone come across an issue before where when you press the transfer
> button the call gets dropped, I have one user who claims that when one
> particular cell phone number calls in and she tried to transfer she loses
> the call.
>
> This is on a 7960 Version: 7.2 (4.0)
>
> CCM 4.1(3) sr3c
>
>
>
>
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
| |
| Voice Noob 2007-12-06, 1:12 pm |
| Why would he need an MTP to transfer a call?
On Dec 6, 2007 12:47 PM, Jonathan Charles <jonvoip@gmail.com> wrote:
> Is there an MRGL assigned to the device pool? Cuz you need an MTP to
> transfer...
>
>
> Jonathan
>
> On Dec 6, 2007 10:59 AM, Nick <csvoip@googlemail.com> wrote:
> loses
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
| |
| Jonathan Charles 2007-12-06, 1:12 pm |
| Because when you hit the transfer key, the call is placed on hold, to
do that, you need an MTP.
Jonathan
On Dec 6, 2007 12:53 PM, Voice Noob <voicenoob@gmail.com> wrote:
> Why would he need an MTP to transfer a call?
>
>
>
>
> On Dec 6, 2007 12:47 PM, Jonathan Charles <jonvoip@gmail.com> wrote:
>
> transfer...
> loses
>
>
| |
|
|
|
| Wes
Ok, I don't believe we have a codec mismatch we are using G711 and we do not
use MOH, the MRGL on the device pool does not contain any MOH resources.
Is there anyway I could check to see if there anything is interupting the
control channel during the media redirection, if the call has dropped.
On 06/12/2007, Wes Sisk <wsisk@cisco.com> wrote:
>
> Not necessarily.
>
> Hold/transfer does place the call on hold. That works fine unless one of
> the call legs meets the following criteria in 4.1:
>
> 1) is h323 to a device that is not h323v2 compliant with empty
> capabilities set (ECS) support
> 2) use the CM SIP trunk
>
> If any call leg uses those then MTP will be required. Otherwise,
> generally, MTP should not be required.
>
> Transfers typically drop calls when:
> 1) there is a codec mismatch between the ingress gateway and the MoH
> server. The codec negotation failure usually puts the call in a state where
> it cannot be resumed or it just immediately drops
> 2) there is an error closing/opening media channels. This happens with
> H.323 endpoints that do not support ECS. It happens with SIP endpoints
> that do not handle the re-invite. It happens when there is a network
> condition that delays or interrupts the control channel (h323, sip, mgcp
> signaling) during the media redirection.
>
> /Wes
>
> Jonathan Charles wrote:
>
> Because when you hit the transfer key, the call is placed on hold, to
> do that, you need an MTP.
>
>
> Jonathan
>
> On Dec 6, 2007 12:53 PM, Voice Noob <voicenoob@gmail.com> <voicenoob@gmail.com> wrote:
>
>
> Why would he need an MTP to transfer a call?
>
>
>
>
> On Dec 6, 2007 12:47 PM, Jonathan Charles <jonvoip@gmail.com> <jonvoip@gmail.com> wrote:
>
>
>
> Is there an MRGL assigned to the device pool? Cuz you need an MTP to
>
>
> transfer...
>
>
> Jonathan
>
>
>
>
> On Dec 6, 2007 10:59 AM, Nick <csvoip@googlemail.com> <csvoip@googlemail.com> wrote:
>
>
> Has anyone come across an issue before where when you press the transfer
> button the call gets dropped, I have one user who claims that when one
> particular cell phone number calls in and she tried to transfer she
>
>
> loses
>
>
> the call.
>
> This is on a 7960 Version: 7.2 (4.0)
>
> CCM 4.1(3) sr3c
>
>
>
>
> ________________________________________
_______
> cisco-voip mailing listcisco-voip@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-voip
>
> ________________________________________
_______
> cisco-voip mailing listcisco-voip@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-voip
>
> ________________________________________
_______
> cisco-voip mailing listcisco-voip@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
| |
| Jonathan Charles 2007-12-07, 1:11 pm |
| Well, you may want to upgrade to 4.1(3)sr5d and get your phone loads
updated... (the sr5d already contains the latest dev pack)...
Jonathan
On Dec 7, 2007 6:06 AM, Nick <csvoip@googlemail.com> wrote:
> Wes
>
> Ok, I don't believe we have a codec mismatch we are using G711 and we do not
> use MOH, the MRGL on the device pool does not contain any MOH resources.
>
> Is there anyway I could check to see if there anything is interupting the
> control channel during the media redirection, if the call has dropped.
>
>
>
>
>
> On 06/12/2007, Wes Sisk <wsisk@cisco.com> wrote:
> the call legs meets the following criteria in 4.1:
> capabilities set (ECS) support
> generally, MTP should not be required.
> server. The codec negotation failure usually puts the call in a state where
> it cannot be resumed or it just immediately drops
> H.323 endpoints that do not support ECS. It happens with SIP endpoints that
> do not handle the re-invite. It happens when there is a network condition
> that delays or interrupts the control channel (h323, sip, mgcp signaling)
> during the media redirection.
>
>
| |
|
| Would love to but we have over 8000 phones and they don't like down time.
On 07/12/2007, Jonathan Charles <jonvoip@gmail.com> wrote:
>
> Well, you may want to upgrade to 4.1(3)sr5d and get your phone loads
> updated... (the sr5d already contains the latest dev pack)...
>
>
> Jonathan
>
> On Dec 7, 2007 6:06 AM, Nick <csvoip@googlemail.com> wrote:
> not
> the
> of
> where
> with
> that
> condition
> signaling)
> transfer
>
| |
| Ryan Ratliff 2007-12-07, 1:11 pm |
| Even though your MRGL doesn't contain any MOH resources if the MOH
servers are not in any MRG then they can be used by any device on the
system. If you don't intend to use MOH then be sure to either change
the IPVMSA RunFlag service parameter for MOH to False or put the MOH
servers in a dummy MRG not used by any MRGL.
-Ryan
On Dec 7, 2007, at 8:57 AM, Nick wrote:
Would love to but we have over 8000 phones and they don't like down
time.
On 07/12/2007, Jonathan Charles <jonvoip@gmail.com> wrote: Well, you
may want to upgrade to 4.1(3)sr5d and get your phone loads
updated... (the sr5d already contains the latest dev pack)...
Jonathan
On Dec 7, 2007 6:06 AM, Nick <csvoip@googlemail.com> wrote:
> Wes
>
> Ok, I don't believe we have a codec mismatch we are using G711 and
we do not
> use MOH, the MRGL on the device pool does not contain any MOH
resources.
>
> Is there anyway I could check to see if there anything is
interupting the
> control channel during the media redirection, if the call has
dropped.
>
>
>
>
>
> On 06/12/2007, Wes Sisk <wsisk@cisco.com> wrote:
unless one of[vbcol=seagreen]
> the call legs meets the following criteria in 4.1:
> capabilities set (ECS) support
> generally, MTP should not be required.
MoH[vbcol=seagreen]
> server. The codec negotation failure usually puts the call in a
state where
> it cannot be resumed or it just immediately drops
happens with[vbcol=seagreen]
> H.323 endpoints that do not support ECS. It happens with SIP
endpoints that
> do not handle the re-invite. It happens when there is a network
condition
> that delays or interrupts the control channel (h323, sip, mgcp
signaling)
> during the media redirection.
hold, to[vbcol=seagreen]
wrote:[vbcol=seagreen]
MTP to[vbcol=seagreen]
transfer[vbcol=seagreen]
when one[vbcol=seagreen]
>
>
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
| |
| Jonathan Charles 2007-12-07, 1:11 pm |
| Well, then load the new firmware files onto the TFTP server and change
the load for this phone, see if it helps... that would cause no
downtime (other than resetting this phone).
Jonathan
On Dec 7, 2007 7:57 AM, Nick <csvoip@googlemail.com> wrote:
> Would love to but we have over 8000 phones and they don't like down time.
>
>
>
>
> On 07/12/2007, Jonathan Charles <jonvoip@gmail.com> wrote:
> not
> the
> of
> where
> with
> that
> condition
> signaling)
> transfer
>
>
| |
|
| I have already upgraded the phone load on this one phone but it appears to
be happening on more than one phone now, I will have to get the users to
monitor it and see which phone it sstill happens to.
On 07/12/2007, Jonathan Charles <jonvoip@gmail.com> wrote:
>
> Well, then load the new firmware files onto the TFTP server and change
> the load for this phone, see if it helps... that would cause no
> downtime (other than resetting this phone).
>
>
> Jonathan
>
> On Dec 7, 2007 7:57 AM, Nick <csvoip@googlemail.com> wrote:
> time.
> we do
> resources.
> interupting
> dropped.
> one
> MoH
> state
> endpoints
> to
> wrote:
> to
> one
> she
>
|
|
|
|
|