Jump to content

Grandstream GRP2612 "No Response" dialing out after 69.1 or 69.1.1 Upgrade, works fine if back on 69.0.8


Telephonetic LLC

Recommended Posts

Grandstream GRP2612 phones display No Response dialing out after upgrade to 69.1. Incoming calls work fine.

Works fine if downgraded back to 69.0.8

Firmware 1.0.9.103.

Disabled the following custom SIP Headers as some articles suggested

Use X-Grandstream-PBX Header > No
Use P-Access-Network-Info Header > No
Use P-Emergency-Info Header > No

Link to comment
Share on other sites

The phones register. They show registered in the phone GUI. It receives calls without an issue as well. Phones ping the IP and FQDN of the PBX (ping test inside the GUI). Where can you see the block history on 69.1.1?

Strange is that it happened to multiple clients, all on different networks and locations. We set up a non-production system to try the update and are trying to reproduce the problem. I experienced the problem on a clean system with just the Trunk, one Tenant, and one extension.

The new Telnyx Trunk had on the SIP caller-ID presentation the following and my test outgoing calls were failing.

 

 

hf: sip:{trunk-ani}@{domain};user=phone

hrpi: sip:{trunk-ani}@{domain};user=phone

 

Changed them to

 

hf: {from}

hrpi: {from}

 

And I was able to dial with my test system. However the phones on the production unit still failed.

Link to comment
Share on other sites

Oh so for example if you call the mailbox from the phone it works? But a call to the trunk fails? Then it would be a good idea to take another look at the trunk headers. Maybe your current setup passes something from the phones to the trunk that the trunk does not like. I would 100 % turn on SIP call messages and dive into the headers. 

Link to comment
Share on other sites

Not to stray too far from the OPs issue.

When using our Yealink phones on the latest build with Telnyx on TLS, calls are not completing. It tries to ring then fail, and after checking the PCAP on the system and on Telnyx, it gave a "Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION", as if they are not able to negotiate codecs. I am guessing something happened between version 68.0.32 and 69.1.2 that doesn't play nice with Telnyx.

I also have an issue when putting incoming calls on hold, once resumed its pure static. That issue is not present when placing outbound calls on hold though.

Both issues are resolved if I roll back to v68.0.32.

Link to comment
Share on other sites

1 hour ago, Vodia PBX said:

Oh so there are a few things with TLS on 69. You need to set an additional parameter to tell it to use TLS:

ice: savp

Maybe you can attach the SIP INVITE and the response here (change the numbers to XXX) then this should become clear.

No longer have the pcap from the system as I uninstalled and reinstalled the PBX since then, but I do have Invite and Response from the Telnyx side:

INVITE sip:+1813xxxxxxx@sip.telnyx.com;user=phone SIP/2.0
Via: SIP/2.0/TLS 34.x.x.x:55514;branch=z9hG4bK-2efef9a6c828658f720b980265180c38;rport
From: <sip:+1656xxxxxxx@sxxxxx.xxxxxxcloud.com;user=phone>;tag=909344563
To: <sip:+1813xxxxxxx@sip.telnyx.com;user=phone>
Call-ID: 0gpsc8s@pbx
CSeq: 9594 INVITE
Max-Forwards: 70
Contact: <sip:xxxxxxxxx@34.x.x.x:55514;transport=tls>
Allow-Events: refer
Supported: 100rel, replaces, norefersub
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
User-Agent: Vodia-PBX/69.1.1
Remote-Party-ID: <sip:+1656xxxxxxx@sxxxxx.xxxxxxcloud.com;user=phone>
Proxy-Authorization: Digest realm="sip.telnyx.com",nonce="29c73b43-ae74-4f53-9f86-3cef85b7aabe",response="51404a08861a08388b0e023d2d6dfbcd",username="stxxxxxxx",uri="sip:+1813xxxxxxx@sip.telnyx.com;user=phone",qop=auth,nc=00000001,cnonce="373284d9",opaque="fbe7a55b-5951-449e-a422-bc203fdedf9f/10.13.37.24",algorithm=MD5
Content-Type: application/sdp
Content-Length: 372

v=0
o=- 2103907024 2103907024 IN IP4 34.x.x.x
s=-
c=IN IP4 34.x.x.x
t=0 0
m=audio 56512 RTP/AVP 0 8 109 9 101
c=IN IP4 34.x.x.x
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000/1
a=sendrecv

 

SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 34.x.x.x:55514;received=34.x.x.x;branch=z9hG4bK-2efef9a6c828658f720b980265180c38;rport=55514
Record-Route: <sip:10.255.0.1;transport=tcp;r2=on;lr;ftag=909344563>
Record-Route: <sip:192.76.120.10:5061;transport=tls;r2=on;lr;ftag=909344563>
From: <sip:+1656xxxxxxx@sxxxxx.xxxxxxcloud.com;user=phone>;tag=909344563
To: <sip:+1813xxxxxxx@sip.telnyx.com;user=phone>;tag=ep3yQgQ8mmKZa
Call-ID: 0gpsc8s@pbx
CSeq: 9594 INVITE
Contact: <sip:+1813xxxxxxx@10.13.37.24:5070;transport=tcp>
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY
Supported: path
Allow-Events: talk, hold, conference, refer
Content-Length: 0
X-Telnyx-Session-ID: 3b30dd96-74f7-11ee-bb75-02420a0de568
X-Telnyx-Leg-ID: 3b30d468-74f7-11ee-8f87-02420a0de568

 

Link to comment
Share on other sites

Well... it is ringing. At least something!

However I would try to set the ice: savp to explicitly turn on RTP/SAVP. You can do that in 69.1.2 in the trunk by switching to the text mode and edit the line there (we need to add it to the HTML page as well). Then it should be doing SRTP for outbound calls. 

Inbound calls are using SRTP properly?

Link to comment
Share on other sites

On 11/2/2023 at 3:36 PM, Vodia PBX said:

Well... it is ringing. At least something!

However I would try to set the ice: savp to explicitly turn on RTP/SAVP. You can do that in 69.1.2 in the trunk by switching to the text mode and edit the line there (we need to add it to the HTML page as well). Then it should be doing SRTP for outbound calls. 

Inbound calls are using SRTP properly?

Sorry for taking so long to get back to you. Inbound calls are the same, it rings once quickly then ends the call. I will try your solution now.

Link to comment
Share on other sites

On 11/2/2023 at 3:36 PM, Vodia PBX said:

Well... it is ringing. At least something!

However I would try to set the ice: savp to explicitly turn on RTP/SAVP. You can do that in 69.1.2 in the trunk by switching to the text mode and edit the line there (we need to add it to the HTML page as well). Then it should be doing SRTP for outbound calls. 

Inbound calls are using SRTP properly?

After changing that option in text mode. It fixed both issues (Calls ending, static when resuming call on hold). 

Was that listed in the change logs? I didn't see it.

 

Link to comment
Share on other sites

This problem was introduced with the video calling rework of the SDP handling. WebRTC is massively using SDP and with it comes a cleanup of the SDP parsing. Before 69, the PBX was tolerant (if not ignorant) with the media types, and RTP/AVP was seen as equivalent to RTP/SAVP. However it is not, and the tolerance could lead to static white noise. Now the PBX is more strict, and thus the trunks need explicitly be instructed to use RTP/SAVP. We are trying to figure out an automatic way to upgrade those trunks, but so far the manual change is the only way. The next build will at least have the templates for new trunks corrected. 

Link to comment
Share on other sites

On 11/12/2023 at 7:53 AM, Vodia PBX said:

This problem was introduced with the video calling rework of the SDP handling. WebRTC is massively using SDP and with it comes a cleanup of the SDP parsing. Before 69, the PBX was tolerant (if not ignorant) with the media types, and RTP/AVP was seen as equivalent to RTP/SAVP. However it is not, and the tolerance could lead to static white noise. Now the PBX is more strict, and thus the trunks need explicitly be instructed to use RTP/SAVP. We are trying to figure out an automatic way to upgrade those trunks, but so far the manual change is the only way. The next build will at least have the templates for new trunks corrected. 

Ok thanks

Link to comment
Share on other sites

  • 2 weeks later...
  • 3 weeks later...
On 11/27/2023 at 10:21 PM, Fanextech said:

... audio quality goes bad sometimes, Is there any codec that you recommend? 

Generally, transcoding from one codec to another never improves the quality (unless you use some artificial intelligence magic). In other words, if your SIP trunk does only use G.711 there is no point using anything like OPUS.

That being said, G.711 is bad when it comes to packet loss. Especially on mobile devices it makes sense to use OPUS even though the quality without packet loss might be slightly lower than with G.711 because in situations where the packet loss is high, users will hear a huge difference. 

In any case, I would recommend to stay from old codecs like G.722 or G.726 and even iLBC. In a nutshell its G.711 or OPUS today.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...