<div dir="ltr">I'm interested in this issue, and I don't see how the g711 codec, in and of itself, could cause an issue like the one described.  The only thing I can think of is that it was causing a transcoder to be invoked and there's actually an issue with the transcoder invocation.  For example, if the H323 GW in CUCM did not have a transcoding resource available, being that it was the g711 side.<br><div><br></div><div>Is the H323 GW remote over the WAN to the IP Phone?  Is that why you're using g729?</div></div><br><div class="gmail_quote">On Thu Feb 12 2015 at 12:30:18 PM Dave Wolgast <<a href="mailto:dwolgas1@rochester.rr.com">dwolgas1@rochester.rr.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">To close the loop on this, absolutely none of the information I originally provided was relevant in the end.<div><br></div><div>We had a hard time nailing down the customer as to when the behavior occurred. We finally tracked it down to inbound PSTN calls.</div><div><br></div><div>On an old H.323 gateway which was handling the inbound traffic, we found the preference 1 dial-peer had a 'codec g711ulaw' on it when it should have been forcing g729r8. The pref 2 & 3 dial-peers were configured correctly.</div><div><br></div><div>This was causing some sort of race condition with the skinny call signalling to the phone.</div><div><br></div><div>Updating the dial-peer fixed it immediately.</div><div><br></div><div>Thanks to all of you who helped with this!</div></div><div class="gmail_extra"></div><div class="gmail_extra"><br clear="all"><div><br clear="all"><div><div>Dave Wolgast<br>Livonia, NY</div></div>
</div>
<br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 30, 2015 at 12:34 PM, Dave Wolgast <span dir="ltr"><<a href="mailto:dwolgas1@rochester.rr.com" target="_blank">dwolgas1@rochester.rr.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">7942G running SCCP 9.3(1)SR3 on CUCM 9.1(2)<div><br></div><div>Phone has a single, non-shared DN with no CFA set. CFB/CFNA set to voicemail. No headset (headset light is OFF)</div><div><br></div><div>Two users (in a several-hundred phone upgrade) report that when the phone rings, they lift the handset, hear dialtone, get an End Call softkey, and the inbound call continues to ring. They can only get the new call, they say, by pressing 'End Call' then 'Answer.'</div><div><br></div><div>We have messed with all combinations of Always Use Prime Line and Auto Line Select/Auto Call Select.</div><div><br></div><div>We have replaced one of the phones. We will try swapping switchports with a known good phone later today.</div><div><br></div><div>Are there any other explanations that anyone can think of for this?<span><font color="#888888"><br clear="all"><div><br clear="all"><div><div>Dave Wolgast<br>Livonia, NY</div></div>
</div>
</font></span></div></div>
</blockquote></div></div>
______________________________<u></u>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/<u></u>mailman/listinfo/cisco-voip</a><br>
</blockquote></div>