VoIP Mailing List Archives

[mbgatherer at gmail.com]

Hi all,


I am working on 1.10.5 (today's build) with proxy_media=true configuration set in dialplan config.
Around 2-3% of total call attempts are CANCELed with "INCOMPATIBLE_DESTINATION" / "AUDIO RTP REPORTS ERROR: [Missing local host]" notification.
I assume that the problem is probably closely connected with codec negotiation, but in my case (proxy_media=true) FS does forward the packets onward and endpoints must agree on the same codec to accept the call.
I have compared all the SIP call flows incoming and outgoing (INVITES, 183) and found no clue.

Some of the important log snippets:
- the call is CANCELed once FS receives 183 and gets first early media packets

8b93b671-b90e-4a0e-aa73-6510a8b9caaf 2020-11-06 19:58:36.832494 [INFO] switch_ivr_originate.c:3801 Sending early media
8b93b671-b90e-4a0e-aa73-6510a8b9caaf 2020-11-06 19:58:36.832494 [DEBUG] switch_core_media.c:8729 PROXY AUDIO RTP [sofia/outside_1/4916222112233@10.20.30.20 (4916222112233@10.20.30.20)] 10.20.30.6:26502->10.20.30.6:26502 codec: 18 ms: 20
8b93b671-b90e-4a0e-aa73-6510a8b9caaf 2020-11-06 19:58:36.832494 [ERR] switch_core_media.c:9669 AUDIO RTP REPORTS ERROR: [Missing local host]
8b93b671-b90e-4a0e-aa73-6510a8b9caaf 2020-11-06 19:58:36.832494 [NOTICE] switch_core_media.c:9670 Hangup sofia/outside_1/4916222112233@10.20.30.20 (4916222112233@10.20.30.20) [CS_EXECUTE] [INCOMPATIBLE_DESTINATION]
a0f2b4f7-8ecd-435d-b66e-444e4d2c65e6 2020-11-06 19:58:36.832494 [DEBUG] switch_ivr_originate.c:3808 sofia/outside_1/4916222112233@10.20.30.20 (4916222112233@10.20.30.20) Media Establishment Failed.
a0f2b4f7-8ecd-435d-b66e-444e4d2c65e6 2020-11-06 19:58:36.832494 [NOTICE] switch_ivr_originate.c:3810 Hangup sofia/outside_1/3144917111223344 [CS_CONSUME_MEDIA] [INCOMPATIBLE_DESTINATION]
8b93b671-b90e-4a0e-aa73-6510a8b9caaf 2020-11-06 19:58:36.832494 [DEBUG] switch_ivr_originate.c:3995 Originate Resulted in Error Cause: 88 [INCOMPATIBLE_DESTINATION]
a0f2b4f7-8ecd-435d-b66e-444e4d2c65e6 2020-11-06 19:58:36.832494 [DEBUG] switch_channel.c:3565 (sofia/outside_1/3144917111223344) Callstate Change DOWN -> EARLY
a0f2b4f7-8ecd-435d-b66e-444e4d2c65e6 2020-11-06 19:58:36.832494 [DEBUG] sofia.c:7339 sofia/outside_1/3144917111223344 skip receive message [PROGRESS_EVENT] (channel is hungup already)
8b93b671-b90e-4a0e-aa73-6510a8b9caaf 2020-11-06 19:58:36.832494 [INFO] mod_dptools.c:3631 Originate Failed.  Cause: INCOMPATIBLE_DESTINATION
a0f2b4f7-8ecd-435d-b66e-444e4d2c65e6 2020-11-06 19:58:36.832494 [DEBUG] switch_core_media.c:12291 sofia/outside_1/3144917111223344 too late.

- incoming (Originator -> FS) SIP INVITE has following SDP
v=0
o=- 1604689110 1604689110 IN IP4 10.20.30.6
s=-
c=IN IP4 10.20.30.6
t=0 0
m=audio 26502 RTP/AVP 18 0 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
a=silenceSupp:off - - - -

- outgoing (FS -> Terminator) SDP of SIP INVITE looks like this (codec transparent)
v=0
o=FreeSWITCH 4241000132 4241000133 IN IP4 10.20.30.20
s=FreeSWITCH
c=IN IP4 10.20.30.20
t=0 0
m=audio 31034 RTP/AVP 18 0 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -

- 183 that is received (Terminator -> FS)
v=0
o=JOANO_SDP 24930105 0 IN IP4 10.20.30.40
s=JOANO-SIP
c=IN IP4 79.133.196.167
t=0 0
m=audio 18200 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=silenceSupp:off - - - -
a=ptime:20

As a result FS tears down the call attempt by sending (FS -> Originator)

SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP 10.20.30.10:5060;received=10.20.30.10;rport=5060;branch=z9hG4bK0609c6993b9c-30-16a290
Via: SIP/2.0/UDP 10.20.30.2:5060;branch=z9hG4bK5765.136934e2.0
Max-Forwards: 66
From: <sip:4916222112233@10.20.30.5:5061;user=phone>;tag=b6b8aec94s
To: <sip:3144917111223344@10.20.30.20 ([email]sip%3A3144917111223344@10.20.30.20[/email]);user=phone>;tag=DcUe4343Uvj8Q
Call-ID: 684d5998-d859dd12-ca30a685-551b1244
CSeq: 1 INVITE
User-Agent: FreeSWITCH-mod_sofia/1.10.5-release~64bit
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION"
Content-Length: 0

and CANCEL (FS -> Terminator)
CANCEL sip:3144917111223344@10.20.30.30:5060 SIP/2.0
Via: SIP/2.0/UDP 10.20.30.20:5080;rport;branch=z9hG4bKK01B9mcmpp5jS
Max-Forwards: 70
From: <sip:4916222112233@10.20.30.20 ([email]sip%3A4916222112233@10.20.30.20[/email])>;tag=g76r9mQeKQN0a
To: <sip:3144917111223344@10.20.30.30:5060>
Call-ID: e788fdfd-9b04-1239-6881-fc15b4264fc0
CSeq: 27790763 CANCEL
Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION"
Content-Length: 0

Could somebody help me to address the issue I am struggling with ?

Detailed debugging logs and sip signalization might be found here:
https://pastebin.com/G0sjGiw8 - FS logs
https://pastebin.com/2Zt6r2mF - SIP logs

Many thanks in advance,
Maciej

[brians at iptel.co]

I dont know if youre sanitizing ips but the sdp from the 'terminator' has an ip that isnt in any of the other signalling. Is that what you expect?

79.x.x.x





On Friday, November 6, 2020, Maciej Bylica <mbgatherer@gmail.com (mbgatherer@gmail.com)> wrote:

[david.villasmil.work a...]

In order to really use bypass_media, the two endpoints MUST see each other, no NAT involved.
Although I read somewhere from Brian that parameter does nothing (but I could be misremembering)
In any case, what do you have in your sofia profile in ext-rtp-ip and ext-sip-ip?


On Fri, 20 Nov 2020 at 10:52, Maciej Bylica <mbgatherer@gmail.com (mbgatherer@gmail.com)> wrote:

[mbgatherer at gmail.com]

Hello,


Sorry for delay, i had to catch up on a few things a bit.
Instead of 79.x.x.x. it should be 10.20.30.41 .... and yes this is what i expect to have.

But i still don't know why FS generates such an event.
As for workaround i use "bypass_media=true" instead of "proxy_media=true", but the question is how to solve it.


Thanks
Maciej









sob., 14 lis 2020 o 09:21 Brian : <brians@iptel.co (brians@iptel.co)> napisał(a):

[mbgatherer at gmail.com]

We normally use "proxy_media=true" and this is the situation that triggers the issue.IPs provided are modified into 10.20.30.xx form, but we use public IPs, so no NAT is involved, hence both parameters have default values like:

    <param name="ext-rtp-ip" value="auto-nat"/>
    <param name="ext-sip-ip" value="auto-nat"/>


Thanks
Maciej.


pt., 20 lis 2020 o 12:42 David Villasmil <david.villasmil.work@gmail.com (david.villasmil.work@gmail.com)> napisał(a):

[brian at freeswitch.com]

set them to "autonat:x.x.x.x" then set local-network-acl



On Fri, Nov 20, 2020 at 6:45 AM Maciej Bylica <mbgatherer@gmail.com (mbgatherer@gmail.com)> wrote:

[mbgatherer at gmail.com]

Sure, will try...

Thanks
MAciej


pt., 20 lis 2020 o 17:47 Brian West <brian@freeswitch.com (brian@freeswitch.com)> napisał(a):

[freeswitch-users at li...]

------ Start of attached email. Subject: Re: [Freeswitch-users] Issue: INCOMPATIBLE_DESTINATION / AUDIO RTP REPORTS ERROR [Missing local host] ------
Try to add this line in the vars.xml

<action application="set" data="media_mix_inbound_outbound_codecs=true"/>

Regards,
Sonny

[mbgatherer at gmail.com]

Hi

Will check that one and update you


Thanks
Maciej.


wt., 24 lis 2020 o 19:42 Sonny Lafuente via FreeSWITCH-users <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)> napisał(a):

[mbgatherer at gmail.com]

Hi,

Unfortunately neither option helped.
- tried to set autonat:MY_PUBLIC_IP and local-network-acl
- added media_mix_inbound_outbound_codecs=true into dialplan/vars


I saw that putting <action application="set" data="bypass_media=true"/> helps to workaround this issue, but this is not exactly what I am looking for.
Frankly I do not think changing anything relating to NAT would help as my server as well as both end servers (traffic originator and terminator) use public IPs (logs i attached have got modified/not-real IPs).


Do you have any other clues, how to track the problem down in order to solve it?


Thanks
Maciej.






sob., 28 lis 2020 o 14:56 Maciej Bylica <mbgatherer@gmail.com (mbgatherer@gmail.com)> napisał(a):

[shaun at sysconfig.cloud]

Have you tried restarting FreeSWITCH?


It's possibly unrelated to your issue but we've recently noticed an increase in 'INCOMPATIBLE_DESTINATION' errors in our environment. We use 'media_mix_inbound_outbound_codecs=true' set as a global variable in '/conf/vars.xml' which works but it seems that over long periods of time FreeSWITCH begins to ignore this, restarting FreeSWITCH resolves the issue for us at least temporarily.


Thanks,
Shaun
From: FreeSWITCH-users <freeswitch-users-bounces@lists.freeswitch.org> on behalf of Maciej Bylica <mbgatherer@gmail.com>
Sent: 29 November 2020 20:56
To: Sonny Lafuente <lafuente_sonny@yahoo.com>; FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>
Subject: Re: [Freeswitch-users] Issue: INCOMPATIBLE_DESTINATION / AUDIO RTP REPORTS ERROR [Missing local host]

Hi,

Unfortunately neither option helped.
- tried to set autonat:MY_PUBLIC_IP and local-network-acl
- added media_mix_inbound_outbound_codecs=true into dialplan/vars


I saw that putting <action application="set" data="bypass_media=true"/> helps to workaround this issue, but this is not exactly what I am looking for.
Frankly I do not think changing anything relating to NAT would help as my server as well as both end servers (traffic originator and terminator) use public IPs (logs i attached have got modified/not-real IPs).


Do you have any other clues, how to track the problem down in order to solve it?


Thanks
Maciej.






sob., 28 lis 2020 o 14:56 Maciej Bylica <mbgatherer@gmail.com (mbgatherer@gmail.com)> napisał(a):

[mbgatherer at gmail.com]

Hi Shaun,

Yes, FreeSWITCH was restarted every time I changed something in the configuration.
I was flooded with "AUDIO RTP REPORTS ERROR: [Missing local host]" and the following "INCOMPATIBLE_DESTINATION" logs the same way.


Thanks
Maciej


pon., 30 lis 2020 o 12:44 Shaun Stokes <shaun@sysconfig.cloud> napisał(a):

[brian at freeswitch.com]

bypass isn't a fix, understanding the signaling and network path are key here, What did you set your local-network-acl to?  And are you sure the settings were applied after setting them?

/b




On Sun, Nov 29, 2020 at 2:21 PM Maciej Bylica <mbgatherer@gmail.com (mbgatherer@gmail.com)> wrote: