VoIP Mailing List Archives

[pirmin at walthert.net]

Hi there

I have the following issue:

A calls B over FreeSWITCH
B sends 180 Ringing without SDP (forwarded by FreeSWITCH to A correctly)
B answers the call with 200 OK but with a=inactive (forwarded by
FreeSWITCH to A correctly)
B sends a ReInvite about 100ms after the 200 OK, but this time with
a=sendrecv
=> while FreeSWITCH is answering with 200 OK and negotiating the codec,
it is not sending any information about this event to A. Means: for A
media is still in inactive state

Any idea what the reason for this behavior could be or how to influence it?

I am using version 1.10.6 on debian 10.8
(1.10.6-release-18-1ff9d0a60e~64bit)

Best regards,

Pirmin


_________________________________________________________________________

The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.

Join our online community to chat in real time https://signalwire.community

Professional FreeSWITCH Services
sales@freeswitch.com
https://freeswitch.com

Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com

[brian at freeswitch.com]

We're not a proxy would be one reason why, Something is missing in your description it seems.  Happen to have the debug logs you can post?

On Tue, Jul 13, 2021 at 9:29 AM Pirmin Walthert <pirmin@walthert.net (pirmin@walthert.net)> wrote:

[pirmin at walthert.net]

I don't think that there is much missing. I will have to simulate this behavior somehow in a lab as I can't turn on full logs on this system (it is a life system under heavy load). The only thing I could provide is sip traces that show the mentioned behavior. The dial process is quite simple: the B leg is called with a simple "<action application="bridge" data="{sip_invite_domain=${invite_domain};user=phone}sofia/gateway_name/xy@z;user=phone"/>

However I was able to influence the behavior with adding the following setting (which wasn't set before):
<param name="inbound-late-negotiation" value="true"/>
now the a=inactive information isn't forwarded anymore to A (this way A still doesn't know about the ReINVITE, but it doesn't need to care anymore about it anyway as it is not in a wrong hold state anymore)
to mention: <param name="renegotiate-codec-on-reinvite" value="true"/> didn't have any influence
So the above (inbound-late-negotiation) fixes the issue for me, however I still guess that the a=sendrecv information should be forwarded when a=inactive is forwarded in the first place.
On 14.07.21 00:36, Brian West wrote:

[brian at freeswitch.com]

What is your hold music set to?

On Wed, Jul 14, 2021 at 11:12 AM Pirmin Walthert <pirmin@walthert.net (pirmin@walthert.net)> wrote:

[pirmin at walthert.net]

<X-PRE-PROCESS cmd="set" data="hold_music=local_stream://moh"/>
autoload_configs/local_stream.conf.xml is containing the defaults and the files in the directories exist



But this is usually not in use as each endpoint is playing its own moh (endpoints are mainly asterisk based systems and sip trunks to providers) => so really putting a call on hold so that FS needs to hold the call should not happen in fact


Why are you asking?




Am 14.07.21 um 18:56 schrieb Brian West:

[brian at freeswitch.com]

Try not setting that variable.

On Wed, Jul 14, 2021 at 2:37 PM Pirmin Walthert <pirmin@walthert.net (pirmin@walthert.net)> wrote:

[pirmin at walthert.net]

You mean not setting hold_music but keeping inbound-late-negotiation or trying again without inbound-late-negotiation and hold_music not set?
I've now first tried it with inbound-late-negotiation=yes and hold_music removed from vars.xml (did a FreeSWITCH restart after removing it from the configuration), the behavior is the same like before: a=inactive is no longer passed to A, but 200 OK is already passed to A between the 200 OK with a=inactive from B and the ReINVITE
With activated inbound-late-negotiation=no and hold_music removed I also get the same behavior as before: a=inactive is forwarded to A, but A is not informed about the change to sendrecv
On 15.07.21 00:45, Brian West wrote: