On Thursday, 10 February, 2011 11:31 PM, Michael Scheidell wrote:
only one that fails is inbound DID to cisco, xfer to poly. did this
on poly fw 3.13c and newest 3.2.4.
who is at fault? cisco? poly? something sipx took for granted on the
cisco and/or poly?
interesting (yes, I need to get the trace)
interesting that a CONFERENCE CALL and not transfer works:
make sure cnf_join_enable is checked (default)
INBOUND to DID on cisco. user answers, talks to caller.
hits 'conference' NOT TRANSFER. calls internal user on a poly who
decides to accept the call. (sees internal DID as caller id)
cisco user then hits 'join', then hangs up.
guess what: it worked.
so, I need two xml traces. one for the attended xfer, one for a
conference all.
For adhoc conference, there is no REFER happening and reINVITEs need not
renegotiate codecs with the calling leg assuming the cisco adhoc conf
performs transcoding. In the case where the DID call is using G.711 and
your cisco to poly ends up with G.722, then you've got a really bad
situation if the DID provider do not support that codec. The reInvite
would fail attempting a renegotiation. You would not experience this
with a direct internal call though, only when the REFER is absorbed by
sipXbridge.
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
