[cisco-voip] Difference between transfer and conference

[Bill Talley]

I'm with Cristobal and am wondering if there's not a routing issue between
the remote IPC devices and the local gateway LAN address (or mgcp bound
interface).

With transfer, the audio stream is between the local gateway and remote IPC
device.  With conference, the audio stream is between the UCM server and
remote IPC device.   Is it possible that the conferences are going through
the software bridge on the UCM server as g711 conferences?

On Wed, Nov 3, 2010 at 3:47 PM, Cristobal Priego
<cristobalpriego at gmail.com>wrote:

> These are my 2 cents on your issue
>
> when the transfer softkey is pressed or the conferene softkey is pressed,
> ccm intructs both phones to "close receive channel & stop media
> transmission. It Stops the RTP 2-way audio Stream
> when transfer/conference is pressed the second time, CCM sends a series of
> Open Receive Channel message to the phones and instructs the phones to Start
> Media Transmission.
>
> So my thoughts are that when the transfer is pressed the 2nd time the RTPs
> aren't being routed to the ipc properly and they get 1 way audio.
>
> 2010/11/3 Scott Voll <svoll.voip at gmail.com>
>
>> No. the calls go out our ASA via the anyconnect client (2.5.1025) out to
>> the IPC user.
>>
>> Transcoders are not being used. (checked with one of our tickets)
>>
>> simply press the transfer say I have X on the line, transfer.
>>
>> work around ends up being conference, I have x on the line, conferenec,
>> then hang up.
>>
>> Technically on a transfer the call coming in is between the VGW and the
>> (g711)operator,  then a second call is placed from the operator to the(g729)
>> IPC user.  then a join is used to connect the two if I understand correctly,
>> thus the VGW and the IPC user should negotiate the Call as G729.
>>
>> maybe I'm not understanding correctly?
>>
>> Scott
>>
>>
>> On Wed, Nov 3, 2010 at 1:08 PM, <george.hendrix at l-3com.com> wrote:
>>
>>>  Sounds like a codec issue to me as well.  Are the calls transferred
>>> back out the same gateway?  Are there DSP transcoders available for the
>>> gateways and phones and UCCX servers?  When you say transfer, is that simply
>>> using their phone or the CCX application?
>>>
>>>
>>>
>>> Bill
>>>
>>>
>>>
>>> *From:* cisco-voip-bounces at puck.nether.net [mailto:
>>> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Scott Voll
>>> *Sent:* Wednesday, November 03, 2010 3:14 PM
>>> *To:* cisco-voip at puck.nether.net
>>> *Subject:* [cisco-voip] Difference between transfer and conference
>>>
>>>
>>>
>>> as far as the call setup / call flow, what is the difference between a
>>> transfer and conference.  Forgive me if someone answered before.
>>>
>>>
>>>
>>> we have been having on going issues with telecommuters (IP communicator)
>>> getting calls transfered to them from our operators.
>>>
>>>
>>>
>>> Call can be transfered and we get the call connected but no way audio
>>> (sounds like a codec issue to me But it doesn't fail.... we have to hang up)
>>> but doing the same thing with the conference button then dropping off the
>>> call works fine.
>>>
>>>
>>>
>>> had about 3-8 TAC cases open on this and still have the same issue.  much
>>> less, but still have the issue.
>>>
>>>
>>>
>>> Call flow is call comes in PSTN via PRI / or CAS T1 on a 3845 running
>>> 15.0.1M3 (one TAC case had us add mgcp behavior g729-variants static-pt
>>>
>>> mgcp behavior dynamically-change-codec-pt disable which helped a lot but
>>> didn't fix the whole problem)
>>>
>>>
>>>
>>> goes to UCCx agent (otherwise known as operator) who transfers to IP
>>> Communicator (telecommuters).  The problem we still have is that sometimes
>>> (2-10 times a day) we get the call transfered but there is no audio.  But if
>>> they instead conference them in then exit the conference it works.
>>>
>>>
>>>
>>> other TAC cases we have open are for IP Communicator and are working on
>>> upgrading all IPC users to 7.0.5.1.
>>>
>>>
>>>
>>> What would a transfer do(or not do), that a conference call doesn't?
>>>
>>>
>>>
>>> any comments / thoughts / answers appreciated.
>>>
>>>
>>>
>>> Scott
>>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>>
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20101103/3db4caf7/attachment.html>