FreeSWITCH re-INVITE breaks CDRs???
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: 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.
Are you sure this is t just fs session timers? Sent from my iPhone
On Sep 21, 2016, at 8:31 PM, Joel Serrano <joel@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Never mind, I found out how to enable the sip-traces on the logfile. As soon as it happens again I will open a JIRA. Thanks. On Thu, Sep 22, 2016 at 9:55 AM, Joel Serrano <joel@gogii.net> wrote:
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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/free switch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (2)
-
Joel Serrano
-
Ken Rice