[FS-9829] FreeSWITCH 200ok to second reINVITE on a dialog doesn't contain an SDP. Created: 07/Dec/16  Updated: 13/Dec/16  Resolved: 13/Dec/16

Status: Resolved
Project: FreeSWITCH
Component/s: mod_sofia
Affects Version/s: 1.6.13, 1.8
Fix Version/s: 1.8

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

Attachments: Text File ccac176c-5b3a-480e-b38a-dd00aab15548.log     PNG File reinvite-notsent.png     File reinvite_t38_200ok_no_sdp_filtered.pcap     XML File t38_outbound.xml    
CPU Architecture:
x86-64
Kernel:
Linux
Userland:
GNU/Linux
Distribution:
Debian
Distribution Version:
Debian 8 jessie
Compiler:
gcc
FreeSWITCH GIT Revision: N/A
GIT Master Revision hash:: N/A

 Description   
When we receive the reinvite we generate an SDP,

 Comments   
Comment by Antonio [ 13/Dec/16 ]
Hi notice the same problem special when there is a first re-invite without t38, the second re-invite that contains the t38 is responded with 200ok without sdp.

If there is only one re-invite with t38 the fax is sent correctly and fs responds with 200ok with t38 parameters in the sdp.

In my setup i have:

local app:txfax ==> provider.

Attach the traffic with the call sip and rtp.
Comment by Brian West [ 13/Dec/16 ]
I'm seeing the same thing but I am unable to replicate it on demand, I have a sipp scenario but it works every time!

/b
Comment by Antonio [ 13/Dec/16 ]
if it helps i attach the log for the call.

edit: forget to say that this log is not from master branch, i cannot update to master in this server because i use loopback channels... i will try to mount a server against this provider to test only.
Comment by Brian West [ 13/Dec/16 ]
Replicated the issue with sipp.
Comment by Brian West [ 13/Dec/16 ]
sipp -m 1 -r 1 -l 1 -s 9102 -sf t38_outbound.xml -mp 25000 -i 190.102.98.5 -mi 190.102.98.5 -p 5066 190.102.98.5:5080 -trace_err -max_invite_retrans 1

on fs_cli

I did this:

bgapi originate {absolute_codec_string=PCMU,ignore_early_media=true}sofia/external/sip:1234@190.102.98.5:5066 &txfax(/fax.tif)

Adapt for your IP and such.
Comment by Brian West [ 13/Dec/16 ]
Tweaks scenario.
Comment by Antonio [ 13/Dec/16 ]
Not sure if it's related, but when configuring my setup i put FS behind the main server and notice that the fax work ok.

The differences is that the first re-invite don't arrive to my test machine, FS as main server don't send the re-invite received from the provider to the FS sending the fax.

All other sip messages are sent correctly.
Comment by Brian West [ 13/Dec/16 ]
Test my sipp scenario, it will replicate the issue, My situation was the same where the remote had sent me another reinvite with audio, prior to switching to t38, thats the key to replicating this particular issue.

I can now replicate it on demand.

/b
Comment by Antonio [ 13/Dec/16 ]
Brian, i couldn't reproduce with your sipp cenario, it gives me an error:

2016-12-13 18:16:37.454118 1481649397.454118: media_port keyword with no audio or video on the current line (
m=image ).
Comment by Mike Jerris [ 13/Dec/16 ]
think this scenario requires latest sipp (you may have to build from source)
Comment by Brian West [ 13/Dec/16 ]
Yes you MUST use the very latest SIPP, I used 3.5.1.

/b
Comment by Antonio [ 13/Dec/16 ]
solved! thanks was my sipp version.
Generated at Tue Aug 14 16:42:09 CDT 2018 using JIRA 7.3.3#73014-sha1:d5be8da522213be2ca9ad7b043c51da6e4cc9754.