[FS-9745] Call to FS WebRTC Gateway fails when no SDP on invite Created: 16/Nov/16  Updated: 22/Dec/16  Resolved: 20/Dec/16

Status: Resolved
Project: FreeSWITCH
Component/s: mod_sofia
Affects Version/s: 1.6.12
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Jose Lopes Assignee: Mike Jerris
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File fix_3pcc_proxy_mod_sofia.c.diff     Text File freeswitch.dpkg.1.6.8.txt     Text File freeswitch.dpkg.notok.1.6.12.txt     Text File freeswitch.notok.1.6.12.log     Text File freeswitch.working.1.6.8.log     Text File freeswitch.xml.fsxml     XML File freeswitch.xml_curl_sofia.conf.xml     XML File uac-inv-without-sdp.xml    
CPU Architecture:
Distribution Version:
Debian 8 jessie
FreeSWITCH GIT Revision: FreeSWITCH Version 1.6.12-20-b91a0a6~64bit (-20-b91a0a6 64bit)
GIT Master Revision hash:: FreeSWITCH Version 1.6.12-20-b91a0a6~64bit (-20-b91a0a6 64bit)

I have created a FreeSwitch WebRTC Gateway that connects between SIP Network and Verto clients.

When i make a call from SIP Network with a INVITE without SDP, the call fails when the verto client answers.

On Sofia profile I activated the next configuration
<param name="enable-3pcc" value="proxy"/>

I have this scenario working on FreeSwitch version 1.6.8, but with version 1.6.12 is not working.

I simulated this issue using sipp and i put the scenario used on attach (uac-inv-without-sdp.xml).

I also have attached the next files:
freeswitch.xml.fsxml -> Freeswitch Configuration
freeswitch.xml_curl_sofia.conf.xml -> sofia.conf by xml_curl
freeswitch.working.1.6.8.log -> log of simulation with freeswitch 1.6.8
freeswitch.notok.1.6.12.log -> log of simulation with freeswitch 1.6.12
freeswitch.dpkg.notok.1.6.12.txt -> dpkg list of package of freeswitch
freeswitch.dpkg.notok.1.6.8.txt -> dpkg list of package of freeswitch

Comment by Jose Lopes [ 15/Dec/16 ]
I notice that the issue FS-9214 introduces some changes at the behavior of 3pcc proxy.

These changes causes this issue.

I created a patch that revert some changes done at FS-9214, so it solves this issue.

I will appreciate If anyone can check my patch and verify if it can be included on FreeSwitch.

Comment by Mike Jerris [ 15/Dec/16 ]
can you please create a pull request for this
Comment by Jose Lopes [ 16/Dec/16 ]
I can't create a branch. I think I don't have permissions.
Comment by Mike Jerris [ 19/Dec/16 ]
you can create your own fork. more info here: https://freeswitch.org/confluence/display/FREESWITCH/Pull+Requests
Comment by Anthony Minessale II [ 20/Dec/16 ]
From the looks of this, this never worked, if you had something that appeared to work it was probably not actually working how you expected.

Please see latest master, where I added support to mod_verto to pass the sdp properly for this to work, note this will result in the SDP containing ICE elements etc which may not be desired. You might want to just set 3pcc=true instead of proxy on a profile bound to call verto endpoints.
Comment by Jose Lopes [ 21/Dec/16 ]
The option 3pcc=true works, but I can't use it because Freeswitch auto-answer the call before the verto client answer the call.

I will try to check latest master.
Comment by Anthony Minessale II [ 21/Dec/16 ]
also later yesterday we added another option.

if you have the channel variable 3pcc_always_gen_sdp=true on the inbound leg set, then you can use =proxy and set that variable in the DP and choose your own codecs with absolute_codec_string and those will be used regardless of what happens in the verto call, but it will create transcoding if you don't have matching codecs.

Comment by Jose Lopes [ 21/Dec/16 ]
I checked latest master and the call without SDP on invite works.

The related changes to this issue will be available to the stable version 1.6 ?
Comment by Anthony Minessale II [ 21/Dec/16 ]
It will be subject to review and if it can be backported and meets the criteria, it will.
Otherwise it will be present in the first 1.8 release coming in 2017.
Comment by Jose Lopes [ 22/Dec/16 ]
Ok. Thanks you for your help.
Generated at Mon Jan 21 11:54:18 CST 2019 using JIRA 7.3.3#73014-sha1:d5be8da522213be2ca9ad7b043c51da6e4cc9754.