Asterisk / Proxy / Freeswitch reinvites race condition
Hi All, We are facing an issue where we have a customer using asterisk which insists on sending connected line updates via SIP UPDATES and REINVITES. I have tried to mitigate this on the customer Asterisk by using all the config instructions you would expect to work but there are still some scenarios where asterisk insists on sending REINVITES with caller ID update to the trunk. I've also tried a number of things on the freeswitch side to try and persuade Asterisk not to send UPDATES or REINVITES without success... SIP Dialog always starts off well but quickly descends into thousands upon thousands of UPDATES and INVITES Freeswitch sends OK to every UPDATE and an OK to the first REINVITE but then starts sending 500 . Asterisk does ACK these errors but immediately sends another UPDATE (again FS sends ok) and INVITE which again we send back a 500 - you can see where I'm going here. This can end up with 1000s of UPDATE,INVITE,500 going on in a SIP dialog and customer reports it is affecting the call audio while this is happening.. I still am unsure of why the audio is affected, the asterisk invites always have SDP so maybe asterisk is opening/closing the port very quickly or something... I've attached a pastie of the first 48 packets of the SIP Trace. This particular call has 2067 SIP packets , mostly INVITE, 500 Olle (OEJ) comments on the Kamailio mailing list: 'If freeswitch believes it already has an open INVITE transaction it should not respond with 500, it should respond with 491 request pending. In that case Asterisk will back off and retry. Please check with the FreeSwitch people and file a bug report so that they can fix this issue. That's the long term solution, all the rest is just quick and dirty fixes. Seems like if this problem is still around, no one filed a bug report.' Should I file a bug report or what are freeswitch users / dev thoughts on this? Maybe there is something I can do in config or is this something that I must address with Asterisk... With older versions that some customers use I was able to stop reinvites completely. With version 11 this functionality is still documented but doesn't work so well... traces are http://pastebin.freeswitch.org/21924 truncated after 48 packets. Many Thanks, Brian
Have you looked at the debug log from freeswitch to see why it is sending the 500? On Feb 2, 2014, at 7:35 AM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi All,
We are facing an issue where we have a customer using asterisk which insists on sending connected line updates via SIP UPDATES and REINVITES.
I have tried to mitigate this on the customer Asterisk by using all the config instructions you would expect to work but there are still some scenarios where asterisk insists on sending REINVITES with caller ID update to the trunk. I've also tried a number of things on the freeswitch side to try and persuade Asterisk not to send UPDATES or REINVITES without success...
SIP Dialog always starts off well but quickly descends into thousands upon thousands of UPDATES and INVITES
Freeswitch sends OK to every UPDATE and an OK to the first REINVITE but then starts sending 500 . Asterisk does ACK these errors but immediately sends another UPDATE (again FS sends ok) and INVITE which again we send back a 500 - you can see where I'm going here.
This can end up with 1000s of UPDATE,INVITE,500 going on in a SIP dialog and customer reports it is affecting the call audio while this is happening.. I still am unsure of why the audio is affected, the asterisk invites always have SDP so maybe asterisk is opening/closing the port very quickly or something...
I've attached a pastie of the first 48 packets of the SIP Trace. This particular call has 2067 SIP packets , mostly INVITE, 500
Olle (OEJ) comments on the Kamailio mailing list:
'If freeswitch believes it already has an open INVITE transaction it should not respond with 500, it should respond with 491 request pending. In that case Asterisk will back off and retry.
Please check with the FreeSwitch people and file a bug report so that they can fix this issue. That's the long term solution, all the rest is just quick and dirty fixes. Seems like if this problem is still around, no one filed a bug report.'
Should I file a bug report or what are freeswitch users / dev thoughts on this?
Maybe there is something I can do in config or is this something that I must address with Asterisk... With older versions that some customers use I was able to stop reinvites completely. With version 11 this functionality is still documented but doesn't work so well...
traces are http://pastebin.freeswitch.org/21924 truncated after 48 packets.
Many Thanks, Brian
Hi Mike, Thanks for looking at this. I have the log level at 7 and this is all that appears immediately before the invite and 500 [DEBUG] switch_core_session.c:1006 Send signal sofia/internal/012345678 [BREAK] I can't see anything else relating to the reinvite. Thanks Brian On 3 February 2014 16:20, Michael Jerris <mike@jerris.com> wrote:
Have you looked at the debug log from freeswitch to see why it is sending the 500?
On Feb 2, 2014, at 7:35 AM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi All,
We are facing an issue where we have a customer using asterisk which insists on sending connected line updates via SIP UPDATES and REINVITES.
I have tried to mitigate this on the customer Asterisk by using all the config instructions you would expect to work but there are still some scenarios where asterisk insists on sending REINVITES with caller ID update to the trunk. I've also tried a number of things on the freeswitch side to try and persuade Asterisk not to send UPDATES or REINVITES without success...
SIP Dialog always starts off well but quickly descends into thousands upon thousands of UPDATES and INVITES
Freeswitch sends OK to every UPDATE and an OK to the first REINVITE but then starts sending 500 . Asterisk does ACK these errors but immediately sends another UPDATE (again FS sends ok) and INVITE which again we send back a 500 - you can see where I'm going here.
This can end up with 1000s of UPDATE,INVITE,500 going on in a SIP dialog and customer reports it is affecting the call audio while this is happening.. I still am unsure of why the audio is affected, the asterisk invites always have SDP so maybe asterisk is opening/closing the port very quickly or something...
I've attached a pastie of the first 48 packets of the SIP Trace. This particular call has 2067 SIP packets , mostly INVITE, 500
Olle (OEJ) comments on the Kamailio mailing list:
'If freeswitch believes it already has an open INVITE transaction it should not respond with 500, it should respond with 491 request pending. In that case Asterisk will back off and retry.
Please check with the FreeSwitch people and file a bug report so that they can fix this issue. That's the long term solution, all the rest is just quick and dirty fixes. Seems like if this problem is still around, no one filed a bug report.'
Should I file a bug report or what are freeswitch users / dev thoughts on this?
Maybe there is something I can do in config or is this something that I must address with Asterisk... With older versions that some customers use I was able to stop reinvites completely. With version 11 this functionality is still documented but doesn't work so well...
traces are http://pastebin.freeswitch.org/21924 truncated after 48 packets.
Many Thanks, Brian
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
What you want is logs from FS side of things to try to catch more info. sofia global siptrace on sofia tracelevel alert sofia loglevel all 9 console loglevel debug And you have to catch the problem at the beginning of when it first starts happening. On Mon, Feb 3, 2014 at 1:08 PM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi Mike,
Thanks for looking at this.
I have the log level at 7 and this is all that appears immediately before the invite and 500
[DEBUG] switch_core_session.c:1006 Send signal sofia/internal/012345678 [BREAK]
I can't see anything else relating to the reinvite.
Thanks Brian
On 3 February 2014 16:20, Michael Jerris <mike@jerris.com> wrote:
Have you looked at the debug log from freeswitch to see why it is sending the 500?
On Feb 2, 2014, at 7:35 AM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi All,
We are facing an issue where we have a customer using asterisk which insists on sending connected line updates via SIP UPDATES and REINVITES.
I have tried to mitigate this on the customer Asterisk by using all the config instructions you would expect to work but there are still some scenarios where asterisk insists on sending REINVITES with caller ID update to the trunk. I've also tried a number of things on the freeswitch side to try and persuade Asterisk not to send UPDATES or REINVITES without success...
SIP Dialog always starts off well but quickly descends into thousands upon thousands of UPDATES and INVITES
Freeswitch sends OK to every UPDATE and an OK to the first REINVITE but then starts sending 500 . Asterisk does ACK these errors but immediately sends another UPDATE (again FS sends ok) and INVITE which again we send back a 500 - you can see where I'm going here.
This can end up with 1000s of UPDATE,INVITE,500 going on in a SIP dialog and customer reports it is affecting the call audio while this is happening.. I still am unsure of why the audio is affected, the asterisk invites always have SDP so maybe asterisk is opening/closing the port very quickly or something...
I've attached a pastie of the first 48 packets of the SIP Trace. This particular call has 2067 SIP packets , mostly INVITE, 500
Olle (OEJ) comments on the Kamailio mailing list:
'If freeswitch believes it already has an open INVITE transaction it should not respond with 500, it should respond with 491 request pending. In that case Asterisk will back off and retry.
Please check with the FreeSwitch people and file a bug report so that they can fix this issue. That's the long term solution, all the rest is just quick and dirty fixes. Seems like if this problem is still around, no one filed a bug report.'
Should I file a bug report or what are freeswitch users / dev thoughts on this?
Maybe there is something I can do in config or is this something that I must address with Asterisk... With older versions that some customers use I was able to stop reinvites completely. With version 11 this functionality is still documented but doesn't work so well...
traces are http://pastebin.freeswitch.org/21924 truncated after 48 packets.
Many Thanks, Brian
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
Hi Anthony - thanks - that is quite another level of logging! Wow.. So the problem freeswitch is giving out about is this: nta.c:2967 agent_recv_request() nta: INVITE (102) going to existing leg nta.c:1341 set_timeout() nta: timer shortened to 200 ms nta.c:5441 incoming_callback() nta_leg(0xb6656790): out-of-order INVITE (102 < 103) It then sends the 500 The CSEQ on the reinvite is 102 - the CSEQ on the UPDATE that asterisk sent just before was 103 .... Does this help or do you require more information. Many Thanks Brian On 3 February 2014 22:50, Anthony Minessale <anthony.minessale@gmail.com> wrote:
What you want is logs from FS side of things to try to catch more info.
sofia global siptrace on sofia tracelevel alert sofia loglevel all 9 console loglevel debug
And you have to catch the problem at the beginning of when it first starts happening.
On Mon, Feb 3, 2014 at 1:08 PM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi Mike,
Thanks for looking at this.
I have the log level at 7 and this is all that appears immediately before the invite and 500
[DEBUG] switch_core_session.c:1006 Send signal sofia/internal/012345678 [BREAK]
I can't see anything else relating to the reinvite.
Thanks Brian
On 3 February 2014 16:20, Michael Jerris <mike@jerris.com> wrote:
Have you looked at the debug log from freeswitch to see why it is sending the 500?
On Feb 2, 2014, at 7:35 AM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi All,
We are facing an issue where we have a customer using asterisk which insists on sending connected line updates via SIP UPDATES and REINVITES.
I have tried to mitigate this on the customer Asterisk by using all the config instructions you would expect to work but there are still some scenarios where asterisk insists on sending REINVITES with caller ID update to the trunk. I've also tried a number of things on the freeswitch side to try and persuade Asterisk not to send UPDATES or REINVITES without success...
SIP Dialog always starts off well but quickly descends into thousands upon thousands of UPDATES and INVITES
Freeswitch sends OK to every UPDATE and an OK to the first REINVITE but then starts sending 500 . Asterisk does ACK these errors but immediately sends another UPDATE (again FS sends ok) and INVITE which again we send back a 500 - you can see where I'm going here.
This can end up with 1000s of UPDATE,INVITE,500 going on in a SIP dialog and customer reports it is affecting the call audio while this is happening.. I still am unsure of why the audio is affected, the asterisk invites always have SDP so maybe asterisk is opening/closing the port very quickly or something...
I've attached a pastie of the first 48 packets of the SIP Trace. This particular call has 2067 SIP packets , mostly INVITE, 500
Olle (OEJ) comments on the Kamailio mailing list:
'If freeswitch believes it already has an open INVITE transaction it should not respond with 500, it should respond with 491 request pending. In that case Asterisk will back off and retry.
Please check with the FreeSwitch people and file a bug report so that they can fix this issue. That's the long term solution, all the rest is just quick and dirty fixes. Seems like if this problem is still around, no one filed a bug report.'
Should I file a bug report or what are freeswitch users / dev thoughts on this?
Maybe there is something I can do in config or is this something that I must address with Asterisk... With older versions that some customers use I was able to stop reinvites completely. With version 11 this functionality is still documented but doesn't work so well...
traces are http://pastebin.freeswitch.org/21924 truncated after 48 packets.
Many Thanks, Brian
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ http://freeswitch.org/g+
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
So, it's doing it because the cseq is out of order not because its a request pending. That clarifies the reason for the 500 so that may alter OEJ's hypothesis. On Mon, Feb 3, 2014 at 5:44 PM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi Anthony - thanks - that is quite another level of logging! Wow..
So the problem freeswitch is giving out about is this:
nta.c:2967 agent_recv_request() nta: INVITE (102) going to existing leg nta.c:1341 set_timeout() nta: timer shortened to 200 ms nta.c:5441 incoming_callback() nta_leg(0xb6656790): out-of-order INVITE (102 < 103)
It then sends the 500
The CSEQ on the reinvite is 102 - the CSEQ on the UPDATE that asterisk sent just before was 103 ....
Does this help or do you require more information.
Many Thanks Brian
On 3 February 2014 22:50, Anthony Minessale <anthony.minessale@gmail.com> wrote:
What you want is logs from FS side of things to try to catch more info.
sofia global siptrace on sofia tracelevel alert sofia loglevel all 9 console loglevel debug
And you have to catch the problem at the beginning of when it first starts happening.
On Mon, Feb 3, 2014 at 1:08 PM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi Mike,
Thanks for looking at this.
I have the log level at 7 and this is all that appears immediately before the invite and 500
[DEBUG] switch_core_session.c:1006 Send signal sofia/internal/012345678 [BREAK]
I can't see anything else relating to the reinvite.
Thanks Brian
On 3 February 2014 16:20, Michael Jerris <mike@jerris.com> wrote:
Have you looked at the debug log from freeswitch to see why it is sending the 500?
On Feb 2, 2014, at 7:35 AM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi All,
We are facing an issue where we have a customer using asterisk which insists on sending connected line updates via SIP UPDATES and REINVITES.
I have tried to mitigate this on the customer Asterisk by using all the config instructions you would expect to work but there are still some scenarios where asterisk insists on sending REINVITES with
caller
ID update to the trunk. I've also tried a number of things on the freeswitch side to try and persuade Asterisk not to send UPDATES or REINVITES without success...
SIP Dialog always starts off well but quickly descends into thousands upon thousands of UPDATES and INVITES
Freeswitch sends OK to every UPDATE and an OK to the first REINVITE but then starts sending 500 . Asterisk does ACK these errors but immediately sends another UPDATE (again FS sends ok) and INVITE which again we send back a 500 - you can see where I'm going here.
This can end up with 1000s of UPDATE,INVITE,500 going on in a SIP dialog and customer reports it is affecting the call audio while this is happening.. I still am unsure of why the audio is affected, the asterisk invites always have SDP so maybe asterisk is opening/closing the port very quickly or something...
I've attached a pastie of the first 48 packets of the SIP Trace. This particular call has 2067 SIP packets , mostly INVITE, 500
Olle (OEJ) comments on the Kamailio mailing list:
'If freeswitch believes it already has an open INVITE transaction it should not respond with 500, it should respond with 491 request pending. In that case Asterisk will back off and retry.
Please check with the FreeSwitch people and file a bug report so that they can fix this issue. That's the long term solution, all the rest is just quick and dirty fixes. Seems like if this problem is still around, no one filed a bug report.'
Should I file a bug report or what are freeswitch users / dev thoughts on this?
Maybe there is something I can do in config or is this something that I must address with Asterisk... With older versions that some customers use I was able to stop reinvites completely. With version 11 this functionality is still documented but doesn't work so well...
traces are http://pastebin.freeswitch.org/21924 truncated after 48 packets.
Many Thanks, Brian
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ http://freeswitch.org/g+
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
Thanks for your help Anthony / Michael and thanks for making software so amazing. Brian On 4 February 2014 00:02, Anthony Minessale <anthony.minessale@gmail.com> wrote:
So, it's doing it because the cseq is out of order not because its a request pending. That clarifies the reason for the 500 so that may alter OEJ's hypothesis.
On Mon, Feb 3, 2014 at 5:44 PM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi Anthony - thanks - that is quite another level of logging! Wow..
So the problem freeswitch is giving out about is this:
nta.c:2967 agent_recv_request() nta: INVITE (102) going to existing leg nta.c:1341 set_timeout() nta: timer shortened to 200 ms nta.c:5441 incoming_callback() nta_leg(0xb6656790): out-of-order INVITE (102 < 103)
It then sends the 500
The CSEQ on the reinvite is 102 - the CSEQ on the UPDATE that asterisk sent just before was 103 ....
Does this help or do you require more information.
Many Thanks Brian
On 3 February 2014 22:50, Anthony Minessale <anthony.minessale@gmail.com> wrote:
What you want is logs from FS side of things to try to catch more info.
sofia global siptrace on sofia tracelevel alert sofia loglevel all 9 console loglevel debug
And you have to catch the problem at the beginning of when it first starts happening.
On Mon, Feb 3, 2014 at 1:08 PM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi Mike,
Thanks for looking at this.
I have the log level at 7 and this is all that appears immediately before the invite and 500
[DEBUG] switch_core_session.c:1006 Send signal sofia/internal/012345678 [BREAK]
I can't see anything else relating to the reinvite.
Thanks Brian
On 3 February 2014 16:20, Michael Jerris <mike@jerris.com> wrote:
Have you looked at the debug log from freeswitch to see why it is sending the 500?
On Feb 2, 2014, at 7:35 AM, dotnetdub <dotnetdub@gmail.com> wrote:
Hi All,
We are facing an issue where we have a customer using asterisk which insists on sending connected line updates via SIP UPDATES and REINVITES.
I have tried to mitigate this on the customer Asterisk by using all the config instructions you would expect to work but there are still some scenarios where asterisk insists on sending REINVITES with caller ID update to the trunk. I've also tried a number of things on the freeswitch side to try and persuade Asterisk not to send UPDATES or REINVITES without success...
SIP Dialog always starts off well but quickly descends into thousands upon thousands of UPDATES and INVITES
Freeswitch sends OK to every UPDATE and an OK to the first REINVITE but then starts sending 500 . Asterisk does ACK these errors but immediately sends another UPDATE (again FS sends ok) and INVITE which again we send back a 500 - you can see where I'm going here.
This can end up with 1000s of UPDATE,INVITE,500 going on in a SIP dialog and customer reports it is affecting the call audio while this is happening.. I still am unsure of why the audio is affected, the asterisk invites always have SDP so maybe asterisk is opening/closing the port very quickly or something...
I've attached a pastie of the first 48 packets of the SIP Trace. This particular call has 2067 SIP packets , mostly INVITE, 500
Olle (OEJ) comments on the Kamailio mailing list:
'If freeswitch believes it already has an open INVITE transaction it should not respond with 500, it should respond with 491 request pending. In that case Asterisk will back off and retry.
Please check with the FreeSwitch people and file a bug report so that they can fix this issue. That's the long term solution, all the rest is just quick and dirty fixes. Seems like if this problem is still around, no one filed a bug report.'
Should I file a bug report or what are freeswitch users / dev thoughts on this?
Maybe there is something I can do in config or is this something that I must address with Asterisk... With older versions that some customers use I was able to stop reinvites completely. With version 11 this functionality is still documented but doesn't work so well...
traces are http://pastebin.freeswitch.org/21924 truncated after 48 packets.
Many Thanks, Brian
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ http://freeswitch.org/g+
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ http://freeswitch.org/g+
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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 (3)
-
Anthony Minessale
-
dotnetdub
-
Michael Jerris