I have successfully created an ASP intercom application that works great with my 7940/7960 phones, but I'm having a problem getting it to work with my 7970 phones. Here's what I'm seeing so far: I have my application setup to have the phones start an intercom session from IP to IP listening and transmitting on port 20480. When I start an intercom from a 7940/7960 to a 7970 the first voice transmission goes through fine. The person on the 7970 end hears it fine. Then the 7970 user responds and it's heard by the 7940/7960 user fine. All subsecquent transmissions from the 7970 to the 7940/7960 are also heard fine, but any further transmissions from the 7940/7960 to the 7970 are unheard by the 7970 user.
Actually it doesn't matter who activates the intercom, as long as the 7940/7960 user talks first, or I should say until the 7970 transmits the first time, the 7940/7960 user can be heard by the 7970. Once the 7970 has transmitted, he can no longer hear the 7940/7960 user.
I did some sniffing and found that the reason for this is because after the first transmission from the 7970, he changes ports, and no longer listens to the port specified by the application, but does transmit to the proper port. Every subsecquent transmission by the 7970 comes from a different source port...whereas the 7940/7960's always use the same source port, which also happens to be the application defined port for listening and recieving.
So now that I've probably throughly confused everyone reading this, let me sum up what I'm seeing before I get to my question:
my 7970's start up an intercom session and until their first transmission, work fine. After their first transmission, they change their source port for listening to incoming RTP streams and no longer recieve the RTP packets from the remote party on the intercom. (They send the remote an ICMP port unreachable when they try to communicate back on the specified port)
Has anyone else run into this?
Is there a way to fix this in the programming, or is this a hardware bug/flaw?
When in doubt, blame Cisco ;) Obviously that doesn't always hold true, but there's one thing to be said about Cisco IP telephony.. phones act different depending on model and phone loads.. now with all the "unified" in application names, one could hope that they'll get around to making phones act unified so you have a write once, run anywhere development, but at this point, that's just not the case.. each phone has its quirks and since there's no consolidated list of issues, you end up having to figure this out the hard way.
If a phone doesn't receive on the port it's been told to, then it's a phone bug I'd say.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...