[Freeswitch-users] FreeSWITCH re-INVITE breaks CDRs???

[Joel Serrano]

HI Ken,

I have tried to enable sip-trace (sofia global siptrace on) but although I
see it in console, it doen't get added to logfile.

How can I enable siptrace in the logfiles?

I will open a JIRA as soon as I find a case that happened after enabling
DEBUG logs and siptrace.

Thanks!
Joel.

On Wed, Sep 21, 2016 at 7:47 PM, Ken Rice <krice at freeswitch.org> wrote:

> And if you think this is a bug open anjora and attach a full unedited
> debug log with sip tracing and the xml cdr.
>
> Sent from my iPhone
>
> > On Sep 21, 2016, at 8:31 PM, Joel Serrano <joel at gogii.net> wrote:
> >
> > Hi,
> >
> > As I understand, freeswitch can handle re-invites. Ok till here, but, is
> there any scenario where freeswitch will send a re-invite proactively ?
> >
> > I'm facing the following problem:
> >
> > Inbound call, from a random person to one of our numbers.
> > Call from: +1706288XXXX (random caller)
> > Call to: +1407602XXXX (our number)
> >
> >
> > This is the diagram:
> >
> > <Screen Shot 2016-09-21 at 18.15.16.png>
> >
> >
> > For some reason, after X amount of time, FreeSWITCH sends out an INVITE.
> I don't understand the reason. I have checked and there are no
> session-timers in the initial request that could trigger it.
> >
> > The problem is not the re-invite, the problem is that the CDR for this
> call is messed up, because the sip_from_user ends up being the callee, and
> the sip_to_user ends up being the caller.
> >
> > I use a script to pull full XML cdrs from our database... The CDR for
> this call has the following:
> >
> > $ ./get_cdr_by_uuid.py '1367e1db-2df4-4c97-8b23-304f85493315' | grep -i
> -e sip_from_user -e sip_to_user
> >     <sip_from_user_stripped>17062886161</sip_from_user_stripped>
> >     <sip_from_user>%2B14076027616</sip_from_user>
> >     <sip_to_user>%2B17062886161</sip_to_user>
> > $
> >
> > As you can see, the sip_to_user, is the caller, (and this is probably
> because of the re-invite from FS to the client). Also, isn't it weird that
> the sip_from_user_stripped still has the original caller correctly, but the
> sip_from_user is updated with the original callee?
> >
> >
> > I don't know if what can be happening.
> >
> > This is happening on FS v1.6.10.
> >
> > I have servers on older versions, I'm trying to reproduce to see if it
> is related to that specific version of FS.
> >
> > I'm also trying to get debug logs, which I currently don't have (because
> they are disabled in prod).
> >
> >
> > Any initial ideas?
> >
> > I think this might be a config setting or something, if it seems like a
> bug or similar I'm happy to open a JIRA.
> >
> >
> > Thanks,
> > Joel.
> >
> >
> >
> >
> >
> > ____________________________________________________________
> _____________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://confluence.freeswitch.org
> > http://www.cluecon.com
> >
> > FreeSWITCH-users mailing list
> > FreeSWITCH-users at lists.freeswitch.org
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> > http://www.freeswitch.org
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160922/56f8b979/attachment-0001.html