PEER SIP trunk not working (Log In trunk works fine)



I have a SIP TRUNK (PEER, no login needed), wont receive calls from outside (it can make them no issue), i hear you all saying its a firewall issue, and i believe it is INSIDE THE GRANDSTREAM due to some security isse.

UCM6208, both ports are SWITCH mode: (single IP address, one port in use)

  • When making a call outside from a deskphone through the UCM to an outside number, works fine, HOWEVER if the call is dropped from the receiving party (my mobile) the call is never dropped in the UCM (no SIP message received from the ISP).
  • When calling the number (from my mobile to the VoIP SIP at the ISP) it never gets to the UCM (no SIP message gets to the UCM).

The same firewall rules work fine for FREEPBX (just changed the internal IP address on the rule)
The UCM6208 works fine with a SIP Trunk that needs login (as expected as the T-sync was started from the UCM end and logs in every 60 seconds).

I seem to remember reading something about the WAN / LAN being different for this, i cant find any documentation from Grandstream, there SIP config has the PEERs logging in.

I am still looking now, i just had a failed migration from freePBX over this.


This is the key - “it never gets to the UCM (no SIP message gets to the UCM).”
In switch mode, the only port used is the LAN port. If you did a network (Wireshark) capture of the incoming call and nothing was seen, then it is not a UCM issue (at least not yet). The capture is showing all data that reaches the port and it is unaffected by anything related to the telephony aspect of the UCM.

It is either a NAT issue or the provider is not sending.

The easiest way to test is to take a phone and remote same using the same SIP port. The SIP will traverse the same as the provider and once you can register and get to vmail and hear the prompt and then leave a message and then call back in and retrieve the message and if heard, then you should be OK.

A register trunk is usually agnostic about the IP seen. In some cases, the provider will use the IP and port seen rather than what is in the messaging as they try and overcome any setting errors that might otherwise send an internal IP in the messaging.

You can make a call while a capture is running and then see what IP is in the Contact header (SIP) and then the Connect header and port in the SDP section, They should both reflect the public IP. If they do, then the UCM seems to be OK and you are back to the firewall and provider.



To be fair here, ive not run a wireshark, it LOOKS LIKE the SIP message never gets to the UCM, Grandstream also seem to list the WAN port as primary when using switch mode (see below), i am sure i have the LAN port in use at the moment (GUI says LAN), will this make a difference? although the phones appear to work perfectly (calls made between them are ok, BLF work correctly, although not tested voicemail for message waiting yet).

Your suggestion is to have a SIP phone register to the UCM from outside? (this kinda makes sense), the system works perfecly with SIP TRUNK registration, just not PEER, sound is both ways, however in PEER mode when the call is dropped a the called mobile, the call never drops in the UCM, it also never receives call from the ISP provider while in PEER mode.

NAT would be my first issue, heres the problem, the FreePBX works fine with the same provider, when we change the IP address on the firewall to the UCM (from freePBX to the UCM) it doesnt work… this all sounds like the firewall to me, however i dont have control of it, the client does.

We know the firewall is working to some degree, when a call is made BEFORE the firewall internal IP was changed to the UCM no voice was heard (no RTP) this only started working once the firewall internal IP address was pointed from freePBX to the UCM… unfortunately this kinda eludes to a UCM issue and not a firewall problem (as it allowed the RTP traffic which was part of the same rules (5060 UDP/TCP and 10000-20000 UDP/TCP)… can see the issue… it looks like 2/3 tests… wireshark with SIP TRUNK and possible remote phone to make sure there isnt an issue with the SIP trunk provider as well as a possible firewall problem.


It may be, but in switch mode you only indicated one port was in use, I assumed the LAN port as it is PoE capable and I only use switch mode and only use the LAN as I like having it use PoE as I also use UPS devices to maintain the system, switch, modem and router during power outages and to protect same from surges, etc.

You will note in the diagram that all ports and devices are on the same LAN segment. It makes no difference which you use.

A wireshark capture will reveal more. Do one and PM me with it if desired.



I am sure i used LAN, as for the POE, Grandstream didnt indicate only ONE port was POE, however its likely the same reason i used LAN (it sounds better to use AND was likely the only one that was POE), its powered from the switch.

I am in agreement, i would assume in switch mode it makes no different which port is used.

I am going to test another peer trunk i have access to with no login on a 6108 (same firmware), then put that same trunk on to the new PBX (6208) at least i will have a base point of a working trunk to test with.

I assume there shouldn’t be any difference between a 6108 and 6208 using the same firmware, especially as the 6208 is set to SWITCH mode?

I might be over thinking this, i am sure its the Cisco (Miraki) firewall, the client is the one with access, i cant see it.

I’ll update here as this progresses (this was supposed to go live yesterday, now it will be next week, its the only think holding up the migration from the working freePBX).

Have you used a 62xx in switch mode with a PEER trunk, no login and seen no issues?

We tested a trunk using PEER through a Watchguard firewall with 5060 UDP, 10000-20000 UDP to a 6108 on the latest firmware, it received calls fine, and disconnected when the outside calling party (my mobile) hung up… This was by no means a FULL test as i couldnt call out due to the PBX design, but in coming had voice both ways and hung up worked both ways.


Yes, peer trunks with any UCM model and version work fine when the settings are correct. You might be able to save a bunch of time by just doing a capture. It may eliminate some of the guess work that comes with a process of elimination scenario.


Check if your with allow guest calls. I have thebsame problem!


Guest calls?

This is a primary trunk, i believe its a traffic issue…

I have wireshark with my UCM with the same setup, so i know what i need to see, will be doing this (likely tomorrow) with the live system as a test, see what i get back.


I am going to shedule some testing, creatine captures for each test to see what i find, i need to document clearly so i can check each wireshark.

I did the same earlier with my own 6108, so i know what i need to see (and its real basic), now i know what i am looking for, it will be easy to see in the other system

To confirm here, i logged data on the LAN pull down (not local)., thsi seem to give me what i needed (seeing packets flowing both ways from the internet to the UCM LAN IP address.

The question on weather its work on the 6208 was aimed at confirming i can really use the LAN port for this to make sure Grandstream didn’t do something odd internally, this problem has me second guessing a lot of basic facts i likely shouldn’t be (like switch mode setting).


Yes sr. I make a ticket in support for this problem… the only way to work my gateway GXW41xx in peer mode is with allow guest calls in my pbx ip… check that!


Making calls wasnt a problem, it was receiving them like no SIP request was coming in to the UCM from the internet (a permiter firewall issue), however i will have some packet captures soon.

What you list is interesting information. Where was this guest setting change they told you to make?


Check configuration in
Pbx settings > sip settings >> “allow guest calls”
Yes the problem is only inbound calls
Make calls to gxw not problem.
In this moment i work with this… i need solution and receive calls from gateway without allow guest calls.
I try to capture packets with my router (mikrotik) and the raw message i dont understand. If you want we talk via whatsapp or other way to work together and fix that.



I have read up on this setting, did you not have any TRUNKS setup for the GXW to receive calls from it (at least a trunk for each SIP line)? The test PEER connection i did, did not have allow guest calls but still worked as designed for incoming calls.

It appears this Guest calls would be to allow the UCM to respond to an incoming SIP messages that doesnt belong to an extension or trunk (so answering a cold anonymous call).


There is no difference in the way the switch ports work between 61XX and 62XX with regard to if LAN.


I have the UCM6208 back in the office, setting up the same test peer SIP truck as i have on the UCM6108 on to the UCM6208 works fine… its likely a LAN / Firewall issue (as assumed).

I will update here as the UCM has to go back out for more testing on the clients site in the next few days. I do have another issue, but will open another thread for that.

The whole network is Cisco Miraki, it was a problem having the UCM obtain and stay live on the network, i had to get the IP on the box manually then connect it to the Cisco switches.


As an update to this (just spent 2 hours onsite testing).

The UCM works fine with a SIP PEER trunk, it however will not with with a Fibernetics SIP PEER trunk, i dont see ANY packets at all from Fibernetics on an inbound call, however it works fine in freePBX (which is set to PEER), this is baffling…

Cant be the firewall as thats passing packets from my own PEER SIP trunk ok, we are assuming its Fibernetics, anyone else had issues with Fibernetics?

I have to send them an email later requesting more details (they are saying they are pushing traffic to an IP address over 5060 which doesnt agree with what i am not seing.


Anyone heard of this before (this is what Fibernetcis said).

If you accept the Options polling then you will receive INVITES on incoming calls,

This was not what was indicated last week (they just said listen to port 5060UDP which we had working this morning, however no SIP invite from fibernetics was ever seen… the system works with listening to port 5060UDP, so whats this about Options Polling, they also mention Metaswitch (which is hardware isnt it?)


Option polling ? Fancy name for it.
In UCM you find it as Heartbeat Detection (on trunk), this is simple SIP Option usually used with peer trunk to check if other side is alive. You will see packet and UCM must respond on it.
UCM support it from box, option on trunk is for UCM check other side. It can work extra as port opener (keep alive).
Metaswitch is soft comapny they provide BSC and other advanced solution for providers.


This is odd, i never receive anything from the ISP SIP provider, but i do have a wireshark with an SIP OPTIONS from the UCM to the ISP SIP trunk, which they responded with 514 Unsupported Media (although it has the correct media for that trunk as confirmed by the provider).

Calls can be made outgoing through that trunk and they do work (with sound both ways), however no SIP messages are ever received back from the ISP SIP trunk provider to the UCM.

Ive pushed some wireshark captures to the ISP SIP trunk provider as it appears they just dont “want” to send SIP packets outbound but are willing to push RTP sound data…

Of course it works with freePBX fine!


it is not about codecs, but rather they are not supporting the options request from the heartbeat.