Over the last few months our softswitch has accumulated 10 "stuck" calls where there's no media traffic. From what the softswitch vendor can tell or guess, it just didn't receive a BYE to tear down the call. We know that most SIP traffic on 5060 is UDP, and UDP is connectionless. How are other vendors and systems managing such scenarios? I suggested a "no media" test where after x hours of no media, to tear down the call and log the info. Thoughts? Frank
This feature (session timers or RTP timers) is usually built into your switch, are you stating that you're not utilizing such a feature? - Darren -- On 6/7/11 12:25 PM, "Frank Bulk" <frnkblk at iname.com> wrote:
Over the last few months our softswitch has accumulated 10 "stuck" calls where there's no media traffic. From what the softswitch vendor can tell or guess, it just didn't receive a BYE to tear down the call.
We know that most SIP traffic on 5060 is UDP, and UDP is connectionless. How are other vendors and systems managing such scenarios? I suggested a "no media" test where after x hours of no media, to tear down the call and log the info.
Thoughts?
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
That feature is not in our softswitch. Sounds like a feature request I need to make. Frank -----Original Message----- From: Darren Schreiber [mailto:d at d-man.org] Sent: Tuesday, June 07, 2011 2:29 PM To: frnkblk at iname.com; VoiceOps at voiceops.org Subject: Re: [VoiceOps] SIP calls that aren't torn down This feature (session timers or RTP timers) is usually built into your switch, are you stating that you're not utilizing such a feature? - Darren -- On 6/7/11 12:25 PM, "Frank Bulk" <frnkblk at iname.com> wrote:
Over the last few months our softswitch has accumulated 10 "stuck" calls where there's no media traffic. From what the softswitch vendor can tell or guess, it just didn't receive a BYE to tear down the call.
We know that most SIP traffic on 5060 is UDP, and UDP is connectionless. How are other vendors and systems managing such scenarios? I suggested a "no media" test where after x hours of no media, to tear down the call and log the info.
Thoughts?
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Is your softswitch from 1982? ;-) OK OK I kid... I am seriously curious what you're using though... These are pretty standard in the open-source world and also on phones and ATAs/media gateway hardware, etc. Maybe you just aren't looking for the right option? Look for anything you can configure known as a "timer" and kick back what you've got... - Darren -- On 6/7/11 12:46 PM, "Frank Bulk" <frnkblk at iname.com> wrote:
That feature is not in our softswitch. Sounds like a feature request I need to make.
Frank
-----Original Message----- From: Darren Schreiber [mailto:d at d-man.org] Sent: Tuesday, June 07, 2011 2:29 PM To: frnkblk at iname.com; VoiceOps at voiceops.org Subject: Re: [VoiceOps] SIP calls that aren't torn down
This feature (session timers or RTP timers) is usually built into your switch, are you stating that you're not utilizing such a feature?
- Darren
--
On 6/7/11 12:25 PM, "Frank Bulk" <frnkblk at iname.com> wrote:
Over the last few months our softswitch has accumulated 10 "stuck" calls where there's no media traffic. From what the softswitch vendor can tell or guess, it just didn't receive a BYE to tear down the call.
We know that most SIP traffic on 5060 is UDP, and UDP is connectionless. How are other vendors and systems managing such scenarios? I suggested a "no media" test where after x hours of no media, to tear down the call and log the info.
Thoughts?
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I was speaking to a developer at Genband about our C15. The softswitch was built by TDM folk, with IP added on later. I'm not surprised that there are certain things mixing that would be assumed in a non-legacy product. Frank -----Original Message----- From: Darren Schreiber [mailto:d at d-man.org] Sent: Tuesday, June 07, 2011 2:57 PM To: frnkblk at iname.com; VoiceOps at voiceops.org Subject: Re: [VoiceOps] SIP calls that aren't torn down Is your softswitch from 1982? ;-) OK OK I kid... I am seriously curious what you're using though... These are pretty standard in the open-source world and also on phones and ATAs/media gateway hardware, etc. Maybe you just aren't looking for the right option? Look for anything you can configure known as a "timer" and kick back what you've got... - Darren -- On 6/7/11 12:46 PM, "Frank Bulk" <frnkblk at iname.com> wrote:
That feature is not in our softswitch. Sounds like a feature request I need to make.
Frank
-----Original Message----- From: Darren Schreiber [mailto:d at d-man.org] Sent: Tuesday, June 07, 2011 2:29 PM To: frnkblk at iname.com; VoiceOps at voiceops.org Subject: Re: [VoiceOps] SIP calls that aren't torn down
This feature (session timers or RTP timers) is usually built into your switch, are you stating that you're not utilizing such a feature?
- Darren
--
On 6/7/11 12:25 PM, "Frank Bulk" <frnkblk at iname.com> wrote:
Over the last few months our softswitch has accumulated 10 "stuck" calls where there's no media traffic. From what the softswitch vendor can tell or guess, it just didn't receive a BYE to tear down the call.
We know that most SIP traffic on 5060 is UDP, and UDP is connectionless. How are other vendors and systems managing such scenarios? I suggested a "no media" test where after x hours of no media, to tear down the call and log the info.
Thoughts?
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 06/07/2011 04:18 PM, Frank Bulk wrote:
I was speaking to a developer at Genband about our C15. The softswitch was built by TDM folk, with IP added on later. I'm not surprised that there are certain things mixing that would be assumed in a non-legacy product.
It doesn't even have a general dialog timeout, apart from RTP dead peer detection? -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
No timers. Not that I can find in the documentation, and not that the support engineer or developer was aware of. Frank -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov Sent: Tuesday, June 07, 2011 3:30 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] SIP calls that aren't torn down On 06/07/2011 04:18 PM, Frank Bulk wrote:
I was speaking to a developer at Genband about our C15. The softswitch was built by TDM folk, with IP added on later. I'm not surprised that there are certain things mixing that would be assumed in a non-legacy product.
It doesn't even have a general dialog timeout, apart from RTP dead peer detection? -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
If you are running an Acme you can also configure it to tear down sessions once a certain time limit has been reached, and just set it to something implausibly long, such as 5 or 6 hours. I'm certain other SBC manufacturers have similar settings to accomplish the same. On Tue, 2011-06-07 at 15:18 -0500, Frank Bulk wrote:
I was speaking to a developer at Genband about our C15. The softswitch was built by TDM folk, with IP added on later. I'm not surprised that there are certain things mixing that would be assumed in a non-legacy product.
Frank
-----Original Message----- From: Darren Schreiber [mailto:d at d-man.org] Sent: Tuesday, June 07, 2011 2:57 PM To: frnkblk at iname.com; VoiceOps at voiceops.org Subject: Re: [VoiceOps] SIP calls that aren't torn down
Is your softswitch from 1982? ;-)
OK OK I kid... I am seriously curious what you're using though... These are pretty standard in the open-source world and also on phones and ATAs/media gateway hardware, etc.
Maybe you just aren't looking for the right option? Look for anything you can configure known as a "timer" and kick back what you've got...
- Darren
Sounds like your "softswitch" is a proxy. Practically any endpoint on the market today will time out the dialog when RTP ceases. On 06/07/2011 03:46 PM, Frank Bulk wrote:
That feature is not in our softswitch. Sounds like a feature request I need to make.
Frank
-----Original Message----- From: Darren Schreiber [mailto:d at d-man.org] Sent: Tuesday, June 07, 2011 2:29 PM To: frnkblk at iname.com; VoiceOps at voiceops.org Subject: Re: [VoiceOps] SIP calls that aren't torn down
This feature (session timers or RTP timers) is usually built into your switch, are you stating that you're not utilizing such a feature?
- Darren
-- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
That's pretty much what Broadworks does with its configurable idle watchdog timer. Of course, every now and then it gets confused and tears down lots of conference bridge legs if the conference runs over 2 hours.....which is the maximum we can set the timer to. --Jon Radel On 6/7/11 3:25 PM, Frank Bulk wrote:
Over the last few months our softswitch has accumulated 10 "stuck" calls where there's no media traffic. From what the softswitch vendor can tell or guess, it just didn't receive a BYE to tear down the call.
We know that most SIP traffic on 5060 is UDP, and UDP is connectionless. How are other vendors and systems managing such scenarios? I suggested a "no media" test where after x hours of no media, to tear down the call and log the info.
Thoughts?
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
BroadSoft normally uses "Session Audits" (defaults to 5 minutes) which is really a SIP RE-INVITE to make sure the other end is still there. If no response is received, the call is torn down. "Hung" calls can still happen due to software bugs, and the vendor should provide a low-level tool to manually kill the calls. The reason BroadSoft doesn't do RTP detection is because it (really the AS and/or NS) are almost never involved in the media stream unless the call is to a MS for say IVR, MOH, etc or a conferencing server. -Scott -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jon Radel Sent: Tuesday, June 07, 2011 3:30 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] SIP calls that aren't torn down That's pretty much what Broadworks does with its configurable idle watchdog timer. Of course, every now and then it gets confused and tears down lots of conference bridge legs if the conference runs over 2 hours.....which is the maximum we can set the timer to. --Jon Radel On 6/7/11 3:25 PM, Frank Bulk wrote:
Over the last few months our softswitch has accumulated 10 "stuck" calls where there's no media traffic. From what the softswitch vendor can tell or guess, it just didn't receive a BYE to tear down the call.
We know that most SIP traffic on 5060 is UDP, and UDP is connectionless. How are other vendors and systems managing such scenarios? I suggested a "no media" test where after x hours of no media, to tear down the call and log the info.
Thoughts?
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 06/07/2011 04:42 PM, Scott Berkman wrote:
BroadSoft normally uses "Session Audits" (defaults to 5 minutes) which is really a SIP RE-INVITE to make sure the other end is still there. If no response is received, the call is torn down. "Hung" calls can still happen due to software bugs, and the vendor should provide a low-level tool to manually kill the calls.
This is BroadSoft marketing bullshit for SSTs, right? (i.e. RFC 4028) -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
This can be disabled on a per customer basis if I remember correctly (re: Broadsoft RFC 4208). -Ryan -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov Sent: Tuesday, June 07, 2011 4:44 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] SIP calls that aren't torn down On 06/07/2011 04:42 PM, Scott Berkman wrote:
BroadSoft normally uses "Session Audits" (defaults to 5 minutes) which is really a SIP RE-INVITE to make sure the other end is still there. If no response is received, the call is torn down. "Hung" calls can still happen due to software bugs, and the vendor should provide a low-level tool to manually kill the calls.
This is BroadSoft marketing bullshit for SSTs, right? (i.e. RFC 4028) -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Nope probably not. Im not familliar with Broadsofts method, but Metaswitch does something similar, and instead of using session timers, uses regular re-invites to detect if all involved endpoints are still alive. We found this a little heavy handed with their stock timers, so we fiddled with it until we were happy. I suspect the rationale here is that using RFC 4028 depends on both far ends supporting that RFC, and implementing it properly, which takes the control out of the softswitch's hands. Using a re-invite as a polling mechanism guarantees the polling works with even older (or cheaper) SIP endpoints that dont support session timers. On Tue, 2011-06-07 at 16:44 -0400, Alex Balashov wrote:
On 06/07/2011 04:42 PM, Scott Berkman wrote:
BroadSoft normally uses "Session Audits" (defaults to 5 minutes) which is really a SIP RE-INVITE to make sure the other end is still there. If no response is received, the call is torn down. "Hung" calls can still happen due to software bugs, and the vendor should provide a low-level tool to manually kill the calls.
This is BroadSoft marketing bullshit for SSTs, right? (i.e. RFC 4028)
On 06/07/2011 04:55 PM, anorexicpoodle wrote:
Im not familliar with Broadsofts method, but Metaswitch does something similar, and instead of using session timers, uses regular re-invites to detect if all involved endpoints are still alive.
We found this a little heavy handed with their stock timers, so we fiddled with it until we were happy.
I suspect the rationale here is that using RFC 4028 depends on both far ends supporting that RFC, and implementing it properly, which takes the control out of the softswitch's hands. Using a re-invite as a polling mechanism guarantees the polling works with even older (or cheaper) SIP endpoints that dont support session timers.
What? RFC 4028 only requires that one endpoint support timers. If the far end does not support them, the softswitch UA will take on the refresher role and send the reinvites, and the other endpoint need not support SSTs or know what they're for, but just to answer them. If both endpoints support SSTs, they'll negotiate the refresher role amongst themselves. But that's optional. In practice, the essence of the standard _is_ the sending of periodic reinvites as a signaling-only method of dead peer detection, not ping-pong between UAs. From 4028 section 7.1: "They are not needed, since the extension works even when only the UAC supports the extension." -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
Understood that they do use re-invites, however the negotiation is conducted between the endpoints, whether the endpoints are effectively the softswitch B2BUA and a media gateway, or the 2 endpoints, however I can appreciate from the softswitch vendor perspective, this is simply not assured that ANY of the endpoints will support it. Metaswitch disregards this entirely and uses a global polling interval, with re-invites determined by the softswitch and not negotiated by endpoints, removing one more potential client side issue. Our Sylantro platofrm used RFC 4028 for this, and we encountered numerous issues where the endpoints simply wouldn't behave appropriately On Tue, 2011-06-07 at 17:00 -0400, Alex Balashov wrote:
On 06/07/2011 04:55 PM, anorexicpoodle wrote:
Im not familliar with Broadsofts method, but Metaswitch does something similar, and instead of using session timers, uses regular re-invites to detect if all involved endpoints are still alive.
We found this a little heavy handed with their stock timers, so we fiddled with it until we were happy.
I suspect the rationale here is that using RFC 4028 depends on both far ends supporting that RFC, and implementing it properly, which takes the control out of the softswitch's hands. Using a re-invite as a polling mechanism guarantees the polling works with even older (or cheaper) SIP endpoints that dont support session timers.
What? RFC 4028 only requires that one endpoint support timers.
If the far end does not support them, the softswitch UA will take on the refresher role and send the reinvites, and the other endpoint need not support SSTs or know what they're for, but just to answer them.
If both endpoints support SSTs, they'll negotiate the refresher role amongst themselves. But that's optional. In practice, the essence of the standard _is_ the sending of periodic reinvites as a signaling-only method of dead peer detection, not ping-pong between UAs.
From 4028 section 7.1:
"They are not needed, since the extension works even when only the UAC supports the extension."
On 06/07/2011 05:09 PM, anorexicpoodle wrote:
Our Sylantro platofrm used RFC 4028 for this, and we encountered numerous issues where the endpoints simply wouldn't behave appropriately
Oh, we know a thing or two about popular endpoints not behaving appropriately. :/ https://issues.asterisk.org/jira/browse/ASTERISK-16801 I vastly prefer endpoints that don't support SSTs, as they remove any such unpredictability and allow our properly SST-supporting, 4028-compliant B2BUA to do its work. When endpoints advertise support for SSTs, the standard says our UA has to accept that, and then, of course, the far-end breaks it. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
I'm sure Alex is going to chime in here eventually but standard SIP Session Timers (RFC 4028) only require support from one endpoint and can use either re-INVITEs or UPDATE. The answer to his question is most likely yes ;). On Tue, Jun 7, 2011 at 4:55 PM, anorexicpoodle <anorexicpoodle at gmail.com> wrote:
Nope probably not.
Im not familliar with Broadsofts method, but Metaswitch does something similar, and instead of using session timers, uses regular re-invites to detect if all involved endpoints are still alive.
We found this a little heavy handed with their stock timers, so we fiddled with it until we were happy.
I suspect the rationale here is that using RFC 4028 depends on both far ends supporting that RFC, and implementing it properly, which takes the control out of the softswitch's hands. Using a re-invite as a polling mechanism guarantees the polling works with even older (or cheaper) SIP endpoints that dont support session timers.
-- Kristian Kielhofner
participants (8)
-
abalashov＠evaristesys.com -
anorexicpoodle＠gmail.com -
d＠d-man.org -
frnkblk＠iname.com -
jradel＠vantage.com -
kristian.kielhofner＠gmail.com -
ryan＠fasttracknetworks.com -
scott＠sberkman.net