Remote phone GXP1782


I installed a GXP1782 at a remote location connecting to a UCM6204. The problem I experience is that I can’t make any calls, internal or external. After I dialed the number the phone doesn’t do anything and after about 30 sec. I get the message “No response”.
I can receive incoming calls without any problem. From the same remote site I can use a GSWave app and connect to the same UCM and everything is working fine, incoming and outgoing. All this points to the setup of the phone but I can’t figure out what has to be changed. Any ideas?


fw of the phone and the ucm?
Did you activate the stun on the phone?
did you do the nat sip and rtp correctly?
I also advise you to force a single codec on the remote phone.


There is much to be known here as calls from the WAVE are either using cellular data or Wi-Fi and the phone is likely not using either given that it does not appear to be a 1782W.

So, let’s assume nothing about the WAVE and let’s focus on the setup -
Start with this post:


The phone I’m using is a GXP1782 and I tried a GXP2135 with the same result. I used the WAVE phone on a WiFI network which is the same subnet as the one used for the physical phones. I followed the instructions in the write-up. The only question I have is what is the difference between WAVE and a physical phone? What is the difference in the WAVE setup compare with the phone’s? With the same UCM I have about 5 WAVE phones at different locations working fine.


The operation of an app compared to a physical ip phone is completely different, but this is a forum not a place to do courses online.
If you give details, someone can help you with your problem.


The fundamental of how either the WAVE and 1782 function are the same, but as I do not know the specifics of how setup on either device, I cannot answer. I have no idea of how the WAVE was programmed - manually, QR or other nor do I know how the extensions associated to each device are configured in the UCM.

Does the 1782 show registered on the UCM? I assume so as you indicated you can receive calls.

Have you conducted a call using the 1782 that has lasted longer than 32 seconds? This is key, so please conduct a call that takes a minute or so and let us know.


1.WAVE was programmed manually and only the account was added. No changes in SIP settings. I can setup an account in WAVE for the extension of the 1782 phone and the wave works incoming and outgoing.
2. 1782 show registered and receives incoming calls, longer than 1 minute…


Make a call from the 1782 to an extension connected to the UCM internally and while doing so go to Maintenance, Troubleshooting and network capture and do a capture of the call. This will show the messaging between both devices and likely show what the issue is. Do not publish on the forum unless you mask the public IPs and/or FQDNS, but not so much so that we can’t tell if private, public or an IP at all. We need to discern the difference in the messaging.


This is capture with different (567 Bytes)


need to see the pcap file, you can PM me and store off to dropbox or other.


Here is the issue:

The 1782 sends the INVITE and the UCM challenges as it should and the 1782 then sends the INVITES again, but this time with its authentication which is correct.

The contact and connect headers are correct, but as you can see, the UCM never appears to respond, so it appears to be the UCM that is at issue.

I also see where ext 300 called 120 and both are at the remote sites and the call was successful.

Further, I see a registration from 120, the challenge from he UCM and this time a registration with the authentication from the 1782 and then an OK from the UCM. The requested expiry is 3600 and the UCM is fine with this, but the 1782 registers again some 9 seconds later and then again 11 seconds after that. So, this is quite odd.

The other extensions that registered during the captured only did so once,

I will take a longer look at it tomorrow.


I advised you to use at most a codec (or limit the amount), but from the track you can see that you left too many active.
This further delays the recording.


It is propably problem with size of packet (packetization).
Turn off some sip headers from there and see if that help.


The parameter creating the problem was “Use P-Access-Network-Info Header” which is YES in default. Once I turned it off the phone start working for outgoing calls too.
“P-Preferred-Identity Header” can be found also on “Basic Settings” page and by change it from “Default” to “No” does the trick, in fact disabling all the ones you suggested.Thanks,


The issue should have been related to the Network Info header as this is what the capture shows:
P-Access-Network-Info: IEEE-EUI-48;eui-48-addr=48-5D-36-51-20-4D
Once this was sent to the UCM, the UCM quit responding. I am guessing that it quit or was not seen as the phone told the UCM to change the access type to eui-48 which the IEEE MAC address standard and the OUI of the MAC refers to Verizon. I have no idea of how this setting may have come into play. Can you advise?

The RFC for the header indicates:
Since SIP systems generally should not care or even know about the access technology, this SIP extension is not for general SIP usage."

The header was not included in the register request; hence why the register was accepted.

The PPI should not be an issue.
The X PBX header is not recognized by the UCM, and I am not familiar with its purpose other than perhaps it being informational.

In any event, glad it is now working. Your issue was the first of this particular type I have come across, so now we both know.


No problem is that PACKET with AUTH is to big and it was divided and not correctly assembled. So UCM do not have reply with AUTH at all. Any extra header removing is fine as far you lower packet size below 1500 :slight_smile:

And yes is seen this few times :frowning:


FYI. After I made the changes described above, I was able to make intercom calls but not outside calls. I changed “Use Privacy Header” to “NO” and this fixed it. Thanks again Marcin for pointing me in the right direction.