VoIP Mailing List Archives

[schoch+freeswitch.org ...]

This office has a bunch of Polycom SoundPoint IP 320 phones, and a single Grandstream HT801 (connected to a FAX machine for outgoing FAXes).


I can make a call from the phones to outside numbers.
I can make a call from the HT801 to local phones.
But I can't call from the HT801 to outside numbers.


The last important thing that happens in the failed call is this:
2021-04-13 17:28:15.260844 [DEBUG] sofia.c:7406 Channel sofia/external/<number> entering state [calling][0]


The difference between the work and not work seems to be this: When I call from a phone to an outside number, it does this:


Local SDP:
v=0
o=FreeSWITCH 1618335260 1618335261 IN IP4 <external-IP>
s=FreeSWITCH
c=IN IP4 <external-IP>
t=0 0
m=audio 25104 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv


When it tries to call from the HT801 to an outside number, it does this:


Local SDP:
v=0
o=FreeSWITCH 1618327543 1618327544 IN IP4 <external-IP>
s=FreeSWITCH
c=IN IP4 <external-IP>
t=0 0
m=audio 32552 RTP/AVP 0 8 102 9 101 103
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40; stereo=1
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:103 telephone-event/48000
a=fmtp:103 0-16
a=ptime:20
a=sendrecv


Is that why it doesn't answer? If so, how do I change it?


I should mention that when I tried this at home, it worked, but when I attempted to install it here at the bookstore, it didn't. The Comcast router at my home is a little different; they use a Netgear router here; and I may have upgraded Freeswitch between the time it worked and now.



--

Steve

[botelist at gmail.com]

I am absolutely no expert on SDP, but that SDP line that begins
a=fmtp:102 useinbandfec=1…
looks to me like it’s trying to set up a video call. I saw this behavior with the newer Polycom VVX501 before I beat those eager beavers into submission.

It also looks like the Grandstream is offering a lot more codecs which you might prefer to trim down to only those necessary to get the job done. Sometimes additional codecs or codecs listed in the “wrong” sequence can cause mystery problems.

You might have to resort to siptrace logging between FS and your carrier.
sofia profile external siptrace on ç or whatever profile handles your provider; or maybe internal to snoop what’s going on between FS and your Grandstream.

Hope this helps.


---
John Boteler
BnC Group U.S.A.




From: FreeSWITCH-users <freeswitch-users-bounces@lists.freeswitch.org> On Behalf Of Steven Schoch
Sent: Tuesday, 13 April, 2021 20:47
To: freeswitch-users <freeswitch-users@lists.freeswitch.org>
Subject: [Freeswitch-users] Why doesn't this call get answered?


This office has a bunch of Polycom SoundPoint IP 320 phones, and a single Grandstream HT801 (connected to a FAX machine for outgoing FAXes).



I can make a call from the phones to outside numbers.

I can make a call from the HT801 to local phones.

But I can't call from the HT801 to outside numbers.



The last important thing that happens in the failed call is this:

2021-04-13 17:28:15.260844 [DEBUG] sofia.c:7406 Channel sofia/external/<number> entering state [calling][0]



The difference between the work and not work seems to be this: When I call from a phone to an outside number, it does this:



Local SDP:
v=0
o=FreeSWITCH 1618335260 1618335261 IN IP4 <external-IP>
s=FreeSWITCH
c=IN IP4 <external-IP>
t=0 0
m=audio 25104 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv



When it tries to call from the HT801 to an outside number, it does this:



Local SDP:

v=0
o=FreeSWITCH 1618327543 1618327544 IN IP4 <external-IP>
s=FreeSWITCH
c=IN IP4 <external-IP>
t=0 0
m=audio 32552 RTP/AVP 0 8 102 9 101 103
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40; stereo=1
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:103 telephone-event/48000
a=fmtp:103 0-16
a=ptime:20
a=sendrecv



Is that why it doesn't answer? If so, how do I change it?



I should mention that when I tried this at home, it worked, but when I attempted to install it here at the bookstore, it didn't. The Comcast router at my home is a little different; they use a Netgear router here; and I may have upgraded Freeswitch between the time it worked and now.



--

Steve

[brian at freeswitch.com]

That's the FMTP for OPUS.  Chances are that invite breaks the Polycom, what does the SDP look like coming back from that invite? I'll be you, it's broken.

/b




On Wed, Apr 14, 2021 at 1:51 PM Bote Man <botelist@gmail.com (botelist@gmail.com)> wrote:

[schoch+freeswitch.org ...]

Calls to the Polycom are not broken - that works. To summarize:

Analog telephone -> HT801 -> Freeswitch -> Polycom SoundPoint works.
Polycom SoundPaint -> Freeswitch -> Flowroute -> mobile phone (or any PSTN number) works.
Analog telephone -> HT801 -> Freeswitch -> Flowroute -> any PSTN number fails.


As John pointed out, it could be the Grandstream codecs are causing Flowroute to ignore the call. I will have to try siptrace.


-- 
Steve


On Wed, Apr 14, 2021 at 12:43 PM Brian West <brian@freeswitch.com (brian@freeswitch.com)> wrote:

[schoch+freeswitch.org ...]

I hate to be needy, but does anyone see any reason why I get no answer to this invite? (I haven't yet generated an invite that works. I guess that will be my next task.)

[schoch+freeswitch.org ...]

Here's the one that works. One difference I notice is that the one that works has a 10-digit Caller-ID, where the one that doesn't work has an 11-digit Caller-ID (starting with 1). There are other differences as well:

send 1157 bytes to udp/[34.210.91.114]:5060 at 11:38:10.114622:
------------------------------------------------------------------------
INVITE sip:1<outside_number>@us-west-or.sip.flowroute.com SIP/2.0
Via: SIP/2.0/UDP <ext_IP>:5089;rport;branch=z9hG4bKXDQ05vU1NB3yD
Max-Forwards: 69
From: "East West Bookshop" <sip:<my_CID>@<ext_IP>>;tag=gymQS2XU0H79e
To: <sip:1<outside_number>@us-west-or.sip.flowroute.com>
Call-ID: bc02d323-1985-123a-9b91-10e7c6b0315b
CSeq: 34745353 INVITE
Contact: <sip:gw+flowroute@<ext_IP>:5089;transport=udp;gw=flowroute>
User-Agent: FreeSWITCH-mod_sofia/1.10.6-release-18-1ff9d0a60e~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 244
X-FS-Support: update_display,send_info
Alert-Info: <internal>
Remote-Party-ID: "East West Bookshop" <sip:<my_CID>@<ext_IP>>;party=calling;screen=yes;privacy=off


v=0
o=FreeSWITCH 1618573488 1618573489 IN IP4 <ext_IP>
s=FreeSWITCH
c=IN IP4 <ext_IP>
t=0 0
m=audio 24802 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20






recv 336 bytes from udp/[34.210.91.114]:5060 at 11:38:10.172288:
------------------------------------------------------------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP <ext_IP>:5089;rport=5089;branch=z9hG4bKXDQ05vU1NB3yD;received=<ext_IP>
From: "East West Bookshop" <sip:<my_CID>@<ext_IP>>;tag=gymQS2XU0H79e
To: <sip:1<outside_number>@us-west-or.sip.flowroute.com>
Call-ID: bc02d323-1985-123a-9b91-10e7c6b0315b
CSeq: 34745353 INVITE
Content-Length: 0


-- 
Steve



On Fri, Apr 16, 2021 at 10:07 AM Steven Schoch <schoch+freeswitch.org@xwin32.com ([email]schoch%2Bfreeswitch.org@xwin32.com[/email])> wrote:

[schoch+freeswitch.org ...]

I have a theory.

The INVITE that originates from the HT801 is bigger, and results in a UDP packet of 1509 bytes vs 1157 bytes for the one that works.


The MTU for Ethernet is 1500, which means the larger UDP packet will get fragmented. Maybe the Netgear router is not handling fragmented UDP packets properly, or maybe the Linux system is sending a jumbo frame and the Netgear router is dropping it. I will investigate...


-- 
Steve


On Fri, Apr 16, 2021 at 11:48 AM Steven Schoch <schoch+freeswitch.org@xwin32.com ([email]schoch%2Bfreeswitch.org@xwin32.com[/email])> wrote:

[grcamauer at gmail.com]

To test if that is true, offer less Codecs.  That will shrink the 9 bytes you need.

Guillermo


On Fri, Apr 16, 2021 at 4:33 PM Steven Schoch <schoch+freeswitch.org@xwin32.com ([email]schoch%2Bfreeswitch.org@xwin32.com[/email])> wrote:

[rawat.anshuman at gmai...]

You might be right. I have seen it happening with a few carriers. Large packets get dropped & one sees no response. You can try with just a single codec (or get rid of some large headers) if this theory is true.



On Fri, Apr 16, 2021 at 3:33 PM Steven Schoch <schoch+freeswitch.org@xwin32.com ([email]schoch%2Bfreeswitch.org@xwin32.com[/email])> wrote:

[schoch+freeswitch.org ...]

I configured the ATA to offer only 2 codecs, which made it get further, until Flowroute asked for authentication, which then made the next packet too big.So I then found another setting in the ATA to stop using the P-Access-Network-Info and P-Emergency-Info headers. This made the packet small enough to complete the call.


Success!


I will ask Flowroute if big packets are dropped on their end, or if it's a problem with the Netgear UDP NAT routing.


-- 
Steve


On Fri, Apr 16, 2021 at 1:17 PM Guillermo Ruiz Camauer <grcamauer@gmail.com (grcamauer@gmail.com)> wrote:

[brian at freeswitch.com]

Ya'll keep giving me the invite, the 100 trying, where is the 200ok?  TEASE!

/b




On Fri, Apr 16, 2021 at 4:36 PM Steven Schoch <schoch+freeswitch.org@xwin32.com ([email]schoch%2Bfreeswitch.org@xwin32.com[/email])> wrote:

[krice at freeswitch.org]

dont forget packet frag reassembly is on the IP stack not the application layer. If the os doesnt reassemble it the app layers dont care

Sent from my iPhone

[mike at freeswitch.org]

Switch to TCP or TLS instead of UDP.

[nycphoneservice at gma...]

Looks like you have an issue with packet fragmentation.
I had a similar issue with grandstream a few years back due to ISP improperly handling fragmentation.

[schoch+freeswitch.org ...]

The problem is probably the NAT gateway. A NAT gateway changes the IP addresses of a packet, meaning it changes the pseudo-header, which is used to compute the checksum. The router can easily recompute the UDP checksum, unless the packet is fragmented, in which case it doesn't have the entire payload to recompute the checksum unless it reassembles the packet, computes the checksum, then forwards the fragments separately. I hear that many NAT routers can't handle IP fragmentation because of this.

-- 
Steve


On Fri, Apr 16, 2021 at 4:40 PM Ken Rice <krice@freeswitch.org (krice@freeswitch.org)> wrote: