If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight! Otherwise, let me toss this out to the group for thoughts and opinions please? We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android). We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address). At thirty (30) minutes into the call, the call ?dropped?. The call was re-established, and again, after thirty minutes, the call dropped. We?re pretty sure the user was in a static position (non-mobile)? and logically assume they were on the same cell tower for both calls that dropped (the Verizon IP was the same). Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone. Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port. So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876. Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark. Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case. It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data. It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy? ? Has anyone had experience with such an occurrence? or any thoughts? Thank you! Mark
If I had to guess Verizon is using CGNAT and since there is no traffic for X amount of time the NAT hole for the SIP traffic is closed. When you send a re-invite at the 30 minute mark that session as far as Verizon's CGNAT devices are concerned have been closed a long time ago. You would need to send a packet to the phone or have the phone send to your switch some sort of traffic (we send SIP OPTIONS every 49 seconds) to ensure that the session stays alive. On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mwiles at akabis.com> wrote:
If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight!
Otherwise, let me toss this out to the group for thoughts and opinions please?
We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android).
We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address).
At thirty (30) minutes into the call, the call ?dropped?. The call was re-established, and again, after thirty minutes, the call dropped.
We?re pretty sure the user was in a static position (non-mobile)? and logically *assume* they were on the same cell tower for both calls that dropped (the Verizon IP was the same).
Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone. Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port. So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876.
Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark.
Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case.
It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data. It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy? ?
Has anyone had experience with such an occurrence? or any thoughts?
Thank you!
Mark
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Hi Dovid, So just thinking about this? granted, there wasn?t SIP traffic for ?X? amount of time? but there would have been RTP? so wouldn?t that have been seen as traffic? Hmmm? but as soon as I typed that, SIP traffic?s on one port? RTP traffic?s on another port? so even with the RTP flowing along and happy? the SIP?s another matter? right? Duh! (I?ve not had my coffee yet) Are you saying that you?re using Metaswitch MaX UC and you?re doing a SIP OPTIONS message every 49 seconds? I totally agree it does sound like a NAT pinhole is closing. It would seem that if that?s the case, Meta would have run into this before and had ?recommendations? to address this. I?ll bounce your thoughts off of them. Thanks! Mark From: Dovid Bender <dovid at telecurve.com> Sent: Thursday, June 10, 2021 8:47 AM To: Mark Wiles <mwiles at akabis.com> Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data If I had to guess Verizon is using CGNAT and since there is no traffic for X amount of time the NAT hole for the SIP traffic is closed. When you send a re-invite at the 30 minute mark that session as far as Verizon's CGNAT devices are concerned have been closed a long time ago. You would need to send a packet to the phone or have the phone send to your switch some sort of traffic (we send SIP OPTIONS every 49 seconds) to ensure that the session stays alive. On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mwiles at akabis.com<mailto:mwiles at akabis.com>> wrote: If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight! Otherwise, let me toss this out to the group for thoughts and opinions please? We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android). We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address). At thirty (30) minutes into the call, the call ?dropped?. The call was re-established, and again, after thirty minutes, the call dropped. We?re pretty sure the user was in a static position (non-mobile)? and logically assume they were on the same cell tower for both calls that dropped (the Verizon IP was the same). Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone. Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port. So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876<http://1.2.3.4:9876>. Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark. Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case. It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data. It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy? ? Has anyone had experience with such an occurrence? or any thoughts? Thank you! Mark _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,lh_KPqz2X9PUlHuKPJ5xHOv6u61RFEXqn0IsKcXIj8NwnKlOz0fW5zqT3A9VPfn4xZipprpMy9tXkVyIfmOS7R3SB2CeIgsA5IPv6mEk65Mh92RokKDZDpu9AsXm&typo=1>
The perimeta should auto-detect the NAT and start a "fast register" in their parlance. You might want to look into this and possibly force nat on your MaXUC instead of using nat autodetect, and make sure fast register is configured. It will handle keeping the signaling portion open for you. https://community.metaswitch.com/support/solutions/articles/76000007855-prod... On 6/10/21 9:18 AM, Mark Wiles wrote:
Hi Dovid,
So just thinking about this? granted, there wasn?t SIP traffic for ?X? amount of time? but there would have been RTP? so wouldn?t that have been seen as traffic?
Hmmm? but as soon as I typed that, SIP traffic?s on one port? RTP traffic?s on another port? so even with the RTP flowing along and happy? the SIP?s another matter? right?? Duh!? (I?ve not had my coffee yet)
Are you saying that you?re using Metaswitch MaX UC and you?re doing a SIP OPTIONS message every 49 seconds?
I totally agree it does sound like a NAT pinhole is closing.? It would seem that if that?s the case, Meta would have run into this before and had ?recommendations? to address this.
I?ll bounce your thoughts off of them.
Thanks!
Mark
*From:* Dovid Bender <dovid at telecurve.com> *Sent:* Thursday, June 10, 2021 8:47 AM *To:* Mark Wiles <mwiles at akabis.com> *Cc:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data
If I had to guess Verizon is using CGNAT and since there is no traffic for X amount of time the NAT hole for the SIP traffic is closed. When you send a re-invite at the 30 minute mark that session as far as Verizon's CGNAT devices are concerned have been closed a long time?ago. You would need to send a packet to the phone or have the phone send to your switch some sort of traffic (we send SIP OPTIONS every 49 seconds) to ensure that the session stays alive.
On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mwiles at akabis.com <mailto:mwiles at akabis.com>> wrote:
If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight!
Otherwise, let me toss this out to the group for thoughts and opinions please?
We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android).
We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address).
At thirty (30) minutes into the call, the call ?dropped?.? The call was re-established, and again, after thirty minutes, the call dropped.
We?re pretty sure the user was in a static position (non-mobile)? and logically _assume_ they were on the same cell tower for both calls that dropped (the Verizon IP was the same).
Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone.? Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port.? So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876 <http://1.2.3.4:9876>.
Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark.
Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case.
It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data.? It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy? ?
Has anyone had experience with such an occurrence? or any thoughts?
Thank you!
Mark
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailma...>
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Paul Timmins Clear Rate Communications Direct: (248) 556-4532 Customer Support: (877) 877-4799 24 Hour Repair: (866) 366-4665 Network Operations: (877) 877-1250 www.clearrate.com This message contains confidential information intended only for the use of the intended recipient(s) and may contain information that is privileged. If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, you are hereby notified that reading, disseminating or copying this message is strictly prohibited. If you have received this message by mistake, please immediately send notification by replying to the message, indicate the message was received by mistake, and then delete the original message immediately thereafter. Thank you. Clear Rate Communications, Inc. 2600 W Big Beaver, Suite 450, Troy, MI 48034.
Paul, that was my thought on the Perimeta. So far, we?ve only had two calls that this issue occurred on? but honestly, not sure how many have 30+ minutes calls on their softphone. I just wonder if this was kind of a one-off issue with a specific Verizon cell? From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Paul Timmins Sent: Thursday, June 10, 2021 11:12 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data The perimeta should auto-detect the NAT and start a "fast register" in their parlance. You might want to look into this and possibly force nat on your MaXUC instead of using nat autodetect, and make sure fast register is configured. It will handle keeping the signaling portion open for you. https://community.metaswitch.com/support/solutions/articles/76000007855-product-advisory-perimeta-and-sip-application-level-gateways-algs<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fcommunity.metaswitch.com%2fsupport%2fsolutions%2farticles%2f76000007855-product-advisory-perimeta-and-sip-application-level-gateways-algs&c=E,1,y0GVFh4InJbiGA_p7LsIOQ53DOKFu20uC7tzS2O0aprTQyEoSEYfcuCoPnEPgoDIKx6FG9ffmXeQPB5RVGEhzUKd-y_ZSrmXJR4DmkX-uw,,&typo=1>- On 6/10/21 9:18 AM, Mark Wiles wrote: Hi Dovid, So just thinking about this? granted, there wasn?t SIP traffic for ?X? amount of time? but there would have been RTP? so wouldn?t that have been seen as traffic? Hmmm? but as soon as I typed that, SIP traffic?s on one port? RTP traffic?s on another port? so even with the RTP flowing along and happy? the SIP?s another matter? right? Duh! (I?ve not had my coffee yet) Are you saying that you?re using Metaswitch MaX UC and you?re doing a SIP OPTIONS message every 49 seconds? I totally agree it does sound like a NAT pinhole is closing. It would seem that if that?s the case, Meta would have run into this before and had ?recommendations? to address this. I?ll bounce your thoughts off of them. Thanks! Mark From: Dovid Bender <dovid at telecurve.com><mailto:dovid at telecurve.com> Sent: Thursday, June 10, 2021 8:47 AM To: Mark Wiles <mwiles at akabis.com><mailto:mwiles at akabis.com> Cc: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data If I had to guess Verizon is using CGNAT and since there is no traffic for X amount of time the NAT hole for the SIP traffic is closed. When you send a re-invite at the 30 minute mark that session as far as Verizon's CGNAT devices are concerned have been closed a long time ago. You would need to send a packet to the phone or have the phone send to your switch some sort of traffic (we send SIP OPTIONS every 49 seconds) to ensure that the session stays alive. On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mwiles at akabis.com<mailto:mwiles at akabis.com>> wrote: If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight! Otherwise, let me toss this out to the group for thoughts and opinions please? We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android). We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address). At thirty (30) minutes into the call, the call ?dropped?. The call was re-established, and again, after thirty minutes, the call dropped. We?re pretty sure the user was in a static position (non-mobile)? and logically assume they were on the same cell tower for both calls that dropped (the Verizon IP was the same). Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone. Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port. So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876<http://1.2.3.4:9876>. Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark. Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case. It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data. It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy? ? Has anyone had experience with such an occurrence? or any thoughts? Thank you! Mark _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,lh_KPqz2X9PUlHuKPJ5xHOv6u61RFEXqn0IsKcXIj8NwnKlOz0fW5zqT3A9VPfn4xZipprpMy9tXkVyIfmOS7R3SB2CeIgsA5IPv6mEk65Mh92RokKDZDpu9AsXm&typo=1> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,0lTU2lUISJDD-BWIAh8i9ZNV1BctI_e5WRnndWjRKbK_rEeyPJoCaenESpkFzMagsVgQ7r72U2yHhnNS9A_s1dlCqzaL7VhDCRip3ENcLKU,&typo=1> -- Paul Timmins Clear Rate Communications Direct: (248) 556-4532 Customer Support: (877) 877-4799 24 Hour Repair: (866) 366-4665 Network Operations: (877) 877-1250 www.clearrate.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.clearrate.com&c=E,1,C...> This message contains confidential information intended only for the use of the intended recipient(s) and may contain information that is privileged. If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, you are hereby notified that reading, disseminating or copying this message is strictly prohibited. If you have received this message by mistake, please immediately send notification by replying to the message, indicate the message was received by mistake, and then delete the original message immediately thereafter. Thank you. Clear Rate Communications, Inc. 2600 W Big Beaver, Suite 450, Troy, MI 48034.
Since I?m as dumb as a bag of hammers when it comes to cellular data? what do you think the NAT timeout might standardly be, before the pin-hole goes away? Strange we?ve not run into this before. From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Paul Timmins Sent: Thursday, June 10, 2021 11:12 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data The perimeta should auto-detect the NAT and start a "fast register" in their parlance. You might want to look into this and possibly force nat on your MaXUC instead of using nat autodetect, and make sure fast register is configured. It will handle keeping the signaling portion open for you. https://community.metaswitch.com/support/solutions/articles/76000007855-product-advisory-perimeta-and-sip-application-level-gateways-algs<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fcommunity.metaswitch.com%2fsupport%2fsolutions%2farticles%2f76000007855-product-advisory-perimeta-and-sip-application-level-gateways-algs&c=E,1,y0GVFh4InJbiGA_p7LsIOQ53DOKFu20uC7tzS2O0aprTQyEoSEYfcuCoPnEPgoDIKx6FG9ffmXeQPB5RVGEhzUKd-y_ZSrmXJR4DmkX-uw,,&typo=1>- On 6/10/21 9:18 AM, Mark Wiles wrote: Hi Dovid, So just thinking about this? granted, there wasn?t SIP traffic for ?X? amount of time? but there would have been RTP? so wouldn?t that have been seen as traffic? Hmmm? but as soon as I typed that, SIP traffic?s on one port? RTP traffic?s on another port? so even with the RTP flowing along and happy? the SIP?s another matter? right? Duh! (I?ve not had my coffee yet) Are you saying that you?re using Metaswitch MaX UC and you?re doing a SIP OPTIONS message every 49 seconds? I totally agree it does sound like a NAT pinhole is closing. It would seem that if that?s the case, Meta would have run into this before and had ?recommendations? to address this. I?ll bounce your thoughts off of them. Thanks! Mark From: Dovid Bender <dovid at telecurve.com><mailto:dovid at telecurve.com> Sent: Thursday, June 10, 2021 8:47 AM To: Mark Wiles <mwiles at akabis.com><mailto:mwiles at akabis.com> Cc: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data If I had to guess Verizon is using CGNAT and since there is no traffic for X amount of time the NAT hole for the SIP traffic is closed. When you send a re-invite at the 30 minute mark that session as far as Verizon's CGNAT devices are concerned have been closed a long time ago. You would need to send a packet to the phone or have the phone send to your switch some sort of traffic (we send SIP OPTIONS every 49 seconds) to ensure that the session stays alive. On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mwiles at akabis.com<mailto:mwiles at akabis.com>> wrote: If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight! Otherwise, let me toss this out to the group for thoughts and opinions please? We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android). We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address). At thirty (30) minutes into the call, the call ?dropped?. The call was re-established, and again, after thirty minutes, the call dropped. We?re pretty sure the user was in a static position (non-mobile)? and logically assume they were on the same cell tower for both calls that dropped (the Verizon IP was the same). Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone. Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port. So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876<http://1.2.3.4:9876>. Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark. Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case. It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data. It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy? ? Has anyone had experience with such an occurrence? or any thoughts? Thank you! Mark _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,lh_KPqz2X9PUlHuKPJ5xHOv6u61RFEXqn0IsKcXIj8NwnKlOz0fW5zqT3A9VPfn4xZipprpMy9tXkVyIfmOS7R3SB2CeIgsA5IPv6mEk65Mh92RokKDZDpu9AsXm&typo=1> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,0lTU2lUISJDD-BWIAh8i9ZNV1BctI_e5WRnndWjRKbK_rEeyPJoCaenESpkFzMagsVgQ7r72U2yHhnNS9A_s1dlCqzaL7VhDCRip3ENcLKU,&typo=1> -- Paul Timmins Clear Rate Communications Direct: (248) 556-4532 Customer Support: (877) 877-4799 24 Hour Repair: (866) 366-4665 Network Operations: (877) 877-1250 www.clearrate.com<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.clearrate.com&c=E,1,C...> This message contains confidential information intended only for the use of the intended recipient(s) and may contain information that is privileged. If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, you are hereby notified that reading, disseminating or copying this message is strictly prohibited. If you have received this message by mistake, please immediately send notification by replying to the message, indicate the message was received by mistake, and then delete the original message immediately thereafter. Thank you. Clear Rate Communications, Inc. 2600 W Big Beaver, Suite 450, Troy, MI 48034.
Perimeta's fast register causes it to refresh faster than once a minute. It doesn't log this in the SAS, but there's a way to verify at the perimeta CLI it's occurring. You might want to have your SE verify that the subscriber is being detected properly as NAT when on the verizon towers, and if not, possibly just force nat all the time on max-uc (since it's really rare there will be a max-uc session that's NOT behind a nat) On 6/10/21 2:30 PM, Mark Wiles wrote:
Since I?m as dumb as a bag of hammers when it comes to cellular data? what do you think the NAT timeout might standardly be, before the pin-hole goes away?
Strange we?ve not run into this before.
*From:* VoiceOps <voiceops-bounces at voiceops.org> *On Behalf Of *Paul Timmins *Sent:* Thursday, June 10, 2021 11:12 AM *To:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data
The perimeta should auto-detect the NAT and start a "fast register" in their parlance. You might want to look into this and possibly force nat on your MaXUC instead of using nat autodetect, and make sure fast register is configured. It will handle keeping the signaling portion open for you.
https://community.metaswitch.com/support/solutions/articles/76000007855-prod... <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fcommunity.metaswitch.com%2fsupport%2fsolutions%2farticles%2f76000007855-product-advisory-perimeta-and-sip-application-level-gateways-algs&c=E,1,y0GVFh4InJbiGA_p7LsIOQ53DOKFu20uC7tzS2O0aprTQyEoSEYfcuCoPnEPgoDIKx6FG9ffmXeQPB5RVGEhzUKd-y_ZSrmXJR4DmkX-uw,,&typo=1>-
On 6/10/21 9:18 AM, Mark Wiles wrote:
Hi Dovid,
So just thinking about this? granted, there wasn?t SIP traffic for ?X? amount of time? but there would have been RTP? so wouldn?t that have been seen as traffic?
Hmmm? but as soon as I typed that, SIP traffic?s on one port? RTP traffic?s on another port? so even with the RTP flowing along and happy? the SIP?s another matter? right?? Duh!? (I?ve not had my coffee yet)
Are you saying that you?re using Metaswitch MaX UC and you?re doing a SIP OPTIONS message every 49 seconds?
I totally agree it does sound like a NAT pinhole is closing.? It would seem that if that?s the case, Meta would have run into this before and had ?recommendations? to address this.
I?ll bounce your thoughts off of them.
Thanks!
Mark
*From:* Dovid Bender <dovid at telecurve.com> <mailto:dovid at telecurve.com> *Sent:* Thursday, June 10, 2021 8:47 AM *To:* Mark Wiles <mwiles at akabis.com> <mailto:mwiles at akabis.com> *Cc:* voiceops at voiceops.org <mailto:voiceops at voiceops.org> *Subject:* Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data
If I had to guess Verizon is using CGNAT and since there is no traffic for X amount of time the NAT hole for the SIP traffic is closed. When you send a re-invite at the 30 minute mark that session as far as Verizon's CGNAT devices are concerned have been closed a long time?ago. You would need to send a packet to the phone or have the phone send to your switch some sort of traffic (we send SIP OPTIONS every 49 seconds) to ensure that the session stays alive.
On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mwiles at akabis.com <mailto:mwiles at akabis.com>> wrote:
If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight!
Otherwise, let me toss this out to the group for thoughts and opinions please?
We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android).
We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address).
At thirty (30) minutes into the call, the call ?dropped?.? The call was re-established, and again, after thirty minutes, the call dropped.
We?re pretty sure the user was in a static position (non-mobile)? and logically _assume_ they were on the same cell tower for both calls that dropped (the Verizon IP was the same).
Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone.? Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port.? So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876 <http://1.2.3.4:9876>.
Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark.
Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case.
It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data.? It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy? ?
Has anyone had experience with such an occurrence? or any thoughts?
Thank you!
Mark
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailma...>
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailma...>
-- Paul Timmins Clear Rate Communications Direct: (248) 556-4532 Customer Support: (877) 877-4799 24 Hour Repair: (866) 366-4665 Network Operations: (877) 877-1250 www.clearrate.com <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.clearrate.com&c=E,1,C...> This message contains confidential information intended only for the use of the intended recipient(s) and may contain information that is privileged. If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, you are hereby notified that reading, disseminating or copying this message is strictly prohibited. If you have received this message by mistake, please immediately send notification by replying to the message, indicate the message was received by mistake, and then delete the original message immediately thereafter. Thank you. Clear Rate Communications, Inc. 2600 W Big Beaver, Suite 450, Troy, MI 48034.
-- Paul Timmins Clear Rate Communications Direct: (248) 556-4532 Customer Support: (877) 877-4799 24 Hour Repair: (866) 366-4665 Network Operations: (877) 877-1250 www.clearrate.com This message contains confidential information intended only for the use of the intended recipient(s) and may contain information that is privileged. If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, you are hereby notified that reading, disseminating or copying this message is strictly prohibited. If you have received this message by mistake, please immediately send notification by replying to the message, indicate the message was received by mistake, and then delete the original message immediately thereafter. Thank you. Clear Rate Communications, Inc. 2600 W Big Beaver, Suite 450, Troy, MI 48034.
uhhhh.... SIP here is UDP, no? There's no connection to close for UDP. The source port for UDP doesn't matter. It's not part of the whole conversation, unless your switch cares that all communications continue to come from the source port. It's connectionless. TCP 5060 isn't even listening on our switches. So, maybe you're doing SIP over TCP? On Thu, 10 Jun 2021, Mark Wiles wrote:
Hi Dovid,
So just thinking about this? granted, there wasn?t SIP traffic for ?X? amount of time? but there would have been RTP? so wouldn?t that have been seen as traffic? Hmmm? but as soon as I typed that, SIP traffic?s on one port? RTP traffic?s on another port? so even with the RTP flowing along and happy? the SIP?s another matter? right? Duh! (I?ve not had my coffee yet)
Are you saying that you?re using Metaswitch MaX UC and you?re doing a SIP OPTIONS message every 49 seconds? I totally agree it does sound like a NAT pinhole is closing. It would seem that if that?s the case, Meta would have run into this before and had ?recommendations? to address this. I?ll bounce your thoughts off of them.
Thanks!
Mark
From: Dovid Bender <dovid at telecurve.com> Sent: Thursday, June 10, 2021 8:47 AM To: Mark Wiles <mwiles at akabis.com> Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data
If I had to guess Verizon is using CGNAT and since there is no traffic for X amount of time the NAT hole for the SIP traffic is closed. When you send a re-invite at the 30 minute mark that session as far as Verizon's CGNAT devices are concerned have been closed a long time ago. You would need to send a packet to the phone or have the phone send to your switch some sort of traffic (we send SIP OPTIONS every 49 seconds) to ensure that the session stays alive.
On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mwiles at akabis.com<mailto:mwiles at akabis.com>> wrote: If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight!
Otherwise, let me toss this out to the group for thoughts and opinions please?
We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android).
We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address). At thirty (30) minutes into the call, the call ?dropped?. The call was re-established, and again, after thirty minutes, the call dropped. We?re pretty sure the user was in a static position (non-mobile)? and logically assume they were on the same cell tower for both calls that dropped (the Verizon IP was the same).
Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone. Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port. So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876<http://1.2.3.4:9876>.
Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark.
Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case.
It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data. It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy? ?
Has anyone had experience with such an occurrence? or any thoughts?
Thank you!
Mark
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,lh_KPqz2X9PUlHuKPJ5xHOv6u61RFEXqn0IsKcXIj8NwnKlOz0fW5zqT3A9VPfn4xZipprpMy9tXkVyIfmOS7R3SB2CeIgsA5IPv6mEk65Mh92RokKDZDpu9AsXm&typo=1>
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
Yes, I think the softphone client does use TCP. -----Original Message----- From: Peter Beckman <beckman at angryox.com> Sent: Thursday, June 10, 2021 4:07 PM To: Mark Wiles <mwiles at akabis.com> Cc: Dovid Bender <dovid at telecurve.com>; voiceops at voiceops.org Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data uhhhh.... SIP here is UDP, no? There's no connection to close for UDP. The source port for UDP doesn't matter. It's not part of the whole conversation, unless your switch cares that all communications continue to come from the source port. It's connectionless. TCP 5060 isn't even listening on our switches. So, maybe you're doing SIP over TCP? On Thu, 10 Jun 2021, Mark Wiles wrote:
Hi Dovid,
So just thinking about this? granted, there wasn?t SIP traffic for ?X? amount of time? but there would have been RTP? so wouldn?t that have been seen as traffic? Hmmm? but as soon as I typed that, SIP traffic?s on one port? RTP traffic?s on another port? so even with the RTP flowing along and happy? the SIP?s another matter? right? Duh! (I?ve not had my coffee yet)
Are you saying that you?re using Metaswitch MaX UC and you?re doing a SIP OPTIONS message every 49 seconds? I totally agree it does sound like a NAT pinhole is closing. It would seem that if that?s the case, Meta would have run into this before and had ?recommendations? to address this. I?ll bounce your thoughts off of them.
Thanks!
Mark
From: Dovid Bender <dovid at telecurve.com> Sent: Thursday, June 10, 2021 8:47 AM To: Mark Wiles <mwiles at akabis.com> Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data
If I had to guess Verizon is using CGNAT and since there is no traffic for X amount of time the NAT hole for the SIP traffic is closed. When you send a re-invite at the 30 minute mark that session as far as Verizon's CGNAT devices are concerned have been closed a long time ago. You would need to send a packet to the phone or have the phone send to your switch some sort of traffic (we send SIP OPTIONS every 49 seconds) to ensure that the session stays alive.
On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mwiles at akabis.com<mailto:mwiles at akabis.com>> wrote: If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight!
Otherwise, let me toss this out to the group for thoughts and opinions please?
We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android).
We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address). At thirty (30) minutes into the call, the call ?dropped?. The call was re-established, and again, after thirty minutes, the call dropped. We?re pretty sure the user was in a static position (non-mobile)? and logically assume they were on the same cell tower for both calls that dropped (the Verizon IP was the same).
Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone. Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port. So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876<http://1.2.3.4:9876>.
Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark.
Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case.
It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data. It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy? ?
Has anyone had experience with such an occurrence? or any thoughts?
Thank you!
Mark
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2f mailman%2flistinfo%2fvoiceops&c=E,1,no2UwuzPowJk-FvIbVFfN7iDcR76xtEq05 6zI_8HqIS4C6el29j0Nho5rwTu6Bue8Wae7bxoYPWpF0Jleg1NU4BEeq9vbdWc_e3VIIUt 4BN8UmTI&typo=1<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpu ck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,lh_KPqz2X9PUlHuKPJ 5xHOv6u61RFEXqn0IsKcXIj8NwnKlOz0fW5zqT3A9VPfn4xZipprpMy9tXkVyIfmOS7R3S B2CeIgsA5IPv6mEk65Mh92RokKDZDpu9AsXm&typo=1>
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.angryox.com%2f&c=E,1,... ---------------------------------------------------------------------------
Not to muddy the waters here with needless pedantry, but: While UDP may be "connectionless", the only way UDP, and in particular, symmetric SIP signalling, can work through NAT is if a stateful firewall + NAT gateway has some awareness (that is, state) of UDP "flows", or groups of packets flowing between ports consistently in some kind of temporary logical association--one might say, the endpoints have a "connection" of sorts... -- Alex On 6/10/21 4:07 PM, Peter Beckman wrote:
uhhhh.... SIP here is UDP, no?
There's no connection to close for UDP.
The source port for UDP doesn't matter. It's not part of the whole conversation, unless your switch cares that all communications continue to come from the source port. It's connectionless.
TCP 5060 isn't even listening on our switches.
So, maybe you're doing SIP over TCP?
On Thu, 10 Jun 2021, Mark Wiles wrote:
Hi Dovid,
So just thinking about this? granted, there wasn?t SIP traffic for ?X? amount of time? but there would have been RTP? so wouldn?t that have been seen as traffic? Hmmm? but as soon as I typed that, SIP traffic?s on one port? RTP traffic?s on another port? so even with the RTP flowing along and happy? the SIP?s another matter? right?? Duh!? (I?ve not had my coffee yet)
Are you saying that you?re using Metaswitch MaX UC and you?re doing a SIP OPTIONS message every 49 seconds? I totally agree it does sound like a NAT pinhole is closing.? It would seem that if that?s the case, Meta would have run into this before and had ?recommendations? to address this. I?ll bounce your thoughts off of them.
Thanks!
Mark
From: Dovid Bender <dovid at telecurve.com> Sent: Thursday, June 10, 2021 8:47 AM To: Mark Wiles <mwiles at akabis.com> Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data
If I had to guess Verizon is using CGNAT and since there is no traffic for X amount of time the NAT hole for the SIP traffic is closed. When you send a re-invite at the 30 minute mark that session as far as Verizon's CGNAT devices are concerned have been closed a long time ago. You would need to send a packet to the phone or have the phone send to your switch some sort of traffic (we send SIP OPTIONS every 49 seconds) to ensure that the session stays alive.
On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mwiles at akabis.com<mailto:mwiles at akabis.com>> wrote: If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight!
Otherwise, let me toss this out to the group for thoughts and opinions please?
We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android).
We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address). At thirty (30) minutes into the call, the call ?dropped?.? The call was re-established, and again, after thirty minutes, the call dropped. We?re pretty sure the user was in a static position (non-mobile)? and logically assume they were on the same cell tower for both calls that dropped (the Verizon IP was the same).
Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone.? Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port.? So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876<http://1.2.3.4:9876>.
Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark.
Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case.
It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data.? It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy?? ?
Has anyone had experience with such an occurrence? or any thoughts?
Thank you!
Mark
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,lh_KPqz2X9PUlHuKPJ5xHOv6u61RFEXqn0IsKcXIj8NwnKlOz0fW5zqT3A9VPfn4xZipprpMy9tXkVyIfmOS7R3SB2CeIgsA5IPv6mEk65Mh92RokKDZDpu9AsXm&typo=1>
--------------------------------------------------------------------------- Peter Beckman????????????????????????????????????????????????? Internet Guy beckman at angryox.com???????????????????????????????? http://www.angryox.com/ ---------------------------------------------------------------------------
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Precisely. And those "NAT table entries" eventually time out. On CG-NAT they often time out aggressively; <60 seconds. Hence sending OPTIONS over SIP over UDP regularly keeps the NAT table entries refreshed and active and therefore the UDP 'connection' open. I've come across firewalls with 30 second timeouts, so we use 25 second keepalives (OPTIONS). Pete
On 11/06/2021, at 8:24 AM, Alex Balashov <abalashov at evaristesys.com> wrote:
Not to muddy the waters here with needless pedantry, but:
While UDP may be "connectionless", the only way UDP, and in particular, symmetric SIP signalling, can work through NAT is if a stateful firewall + NAT gateway has some awareness (that is, state) of UDP "flows", or groups of packets flowing between ports consistently in some kind of temporary logical association--one might say, the endpoints have a "connection" of sorts...
-- Alex
On 6/10/21 4:07 PM, Peter Beckman wrote: uhhhh.... SIP here is UDP, no? There's no connection to close for UDP. The source port for UDP doesn't matter. It's not part of the whole conversation, unless your switch cares that all communications continue to come from the source port. It's connectionless. TCP 5060 isn't even listening on our switches. So, maybe you're doing SIP over TCP? On Thu, 10 Jun 2021, Mark Wiles wrote:
The acme/oracle way of doing Hosted NAT Traversal is to set the expire time down to 30 seconds and have the phones REGISTER every 30 seconds. The SBC eats the registration so it doesn?t overload the switch. If the CGN NAT drops the entry it gets recreated with the new registration in 30 seconds. We have had very good results with the acme/oracle approach From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Pete Mundy <pete at mac.geek.nz> Date: Thursday, June 10, 2021 at 5:11 PM To: VoiceOps <voiceops at voiceops.org> Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data CAUTION: This email originated from outside of Crocker. Do not click links or open attachments unless you recognize the sender and know the content is safe. Precisely. And those "NAT table entries" eventually time out. On CG-NAT they often time out aggressively; <60 seconds. Hence sending OPTIONS over SIP over UDP regularly keeps the NAT table entries refreshed and active and therefore the UDP 'connection' open. I've come across firewalls with 30 second timeouts, so we use 25 second keepalives (OPTIONS). Pete
On 11/06/2021, at 8:24 AM, Alex Balashov <abalashov at evaristesys.com> wrote:
Not to muddy the waters here with needless pedantry, but:
While UDP may be "connectionless", the only way UDP, and in particular, symmetric SIP signalling, can work through NAT is if a stateful firewall + NAT gateway has some awareness (that is, state) of UDP "flows", or groups of packets flowing between ports consistently in some kind of temporary logical association--one might say, the endpoints have a "connection" of sorts...
-- Alex
On 6/10/21 4:07 PM, Peter Beckman wrote: uhhhh.... SIP here is UDP, no? There's no connection to close for UDP. The source port for UDP doesn't matter. It's not part of the whole conversation, unless your switch cares that all communications continue to come from the source port. It's connectionless. TCP 5060 isn't even listening on our switches. So, maybe you're doing SIP over TCP? On Thu, 10 Jun 2021, Mark Wiles wrote:
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
The metaswitch way is that it will do it automatically for you if it thinks you're behind a NAT. So if you force nat, it will do the fast registration automatically. It's one line of config on the sip adjacency for the MaxUC application.
On Jun 10, 2021, at 5:33 PM, Matthew Crocker <matthew at corp.crocker.com> wrote:
The acme/oracle way of doing Hosted NAT Traversal is to set the expire time down to 30 seconds and have the phones REGISTER every 30 seconds. The SBC eats the registration so it doesn?t overload the switch. If the CGN NAT drops the entry it gets recreated with the new registration in 30 seconds.
We have had very good results with the acme/oracle approach
From: VoiceOps <voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>> on behalf of Pete Mundy <pete at mac.geek.nz <mailto:pete at mac.geek.nz>> Date: Thursday, June 10, 2021 at 5:11 PM To: VoiceOps <voiceops at voiceops.org <mailto:voiceops at voiceops.org>> Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data
CAUTION: This email originated from outside of Crocker. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Precisely. And those "NAT table entries" eventually time out. On CG-NAT they often time out aggressively; <60 seconds. Hence sending OPTIONS over SIP over UDP regularly keeps the NAT table entries refreshed and active and therefore the UDP 'connection' open. I've come across firewalls with 30 second timeouts, so we use 25 second keepalives (OPTIONS).
Pete
On 11/06/2021, at 8:24 AM, Alex Balashov <abalashov at evaristesys.com <mailto:abalashov at evaristesys.com>> wrote:
Not to muddy the waters here with needless pedantry, but:
While UDP may be "connectionless", the only way UDP, and in particular, symmetric SIP signalling, can work through NAT is if a stateful firewall + NAT gateway has some awareness (that is, state) of UDP "flows", or groups of packets flowing between ports consistently in some kind of temporary logical association--one might say, the endpoints have a "connection" of sorts...
-- Alex
On 6/10/21 4:07 PM, Peter Beckman wrote: uhhhh.... SIP here is UDP, no? There's no connection to close for UDP. The source port for UDP doesn't matter. It's not part of the whole conversation, unless your switch cares that all communications continue to come from the source port. It's connectionless. TCP 5060 isn't even listening on our switches. So, maybe you're doing SIP over TCP? On Thu, 10 Jun 2021, Mark Wiles wrote:
VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops>_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops>
My concern right now is this issue has only been reported happening twice? to the same person, coming (most likely) off the same cell site (we think he was stationary). One call right after the other. My wholesale partner that complained about it made a stink (as it was his boss that it happened to)? and pretty much knee-jerked in their reaction. I?ve requested they try to replicate? and hear nothing back. So I don?t want to knee-jerk myself to something that may simply be a one-off situation. But all the replies and comments seem valid for consideration and chats with Metaswitch? I mean Microsoft, if it happens again. Any thoughts why maybe it would happen on one cell site? From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Paul Timmins Sent: Thursday, June 10, 2021 10:33 PM To: Matthew Crocker <matthew at corp.crocker.com> Cc: VoiceOps <voiceops at voiceops.org> Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data The metaswitch way is that it will do it automatically for you if it thinks you're behind a NAT. So if you force nat, it will do the fast registration automatically. It's one line of config on the sip adjacency for the MaxUC application. On Jun 10, 2021, at 5:33 PM, Matthew Crocker <matthew at corp.crocker.com<mailto:matthew at corp.crocker.com>> wrote: The acme/oracle way of doing Hosted NAT Traversal is to set the expire time down to 30 seconds and have the phones REGISTER every 30 seconds. The SBC eats the registration so it doesn?t overload the switch. If the CGN NAT drops the entry it gets recreated with the new registration in 30 seconds. We have had very good results with the acme/oracle approach From: VoiceOps <voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>> on behalf of Pete Mundy <pete at mac.geek.nz<mailto:pete at mac.geek.nz>> Date: Thursday, June 10, 2021 at 5:11 PM To: VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data CAUTION: This email originated from outside of Crocker. Do not click links or open attachments unless you recognize the sender and know the content is safe. Precisely. And those "NAT table entries" eventually time out. On CG-NAT they often time out aggressively; <60 seconds. Hence sending OPTIONS over SIP over UDP regularly keeps the NAT table entries refreshed and active and therefore the UDP 'connection' open. I've come across firewalls with 30 second timeouts, so we use 25 second keepalives (OPTIONS). Pete
On 11/06/2021, at 8:24 AM, Alex Balashov <abalashov at evaristesys.com<mailto:abalashov at evaristesys.com>> wrote:
Not to muddy the waters here with needless pedantry, but:
While UDP may be "connectionless", the only way UDP, and in particular, symmetric SIP signalling, can work through NAT is if a stateful firewall + NAT gateway has some awareness (that is, state) of UDP "flows", or groups of packets flowing between ports consistently in some kind of temporary logical association--one might say, the endpoints have a "connection" of sorts...
-- Alex
On 6/10/21 4:07 PM, Peter Beckman wrote: uhhhh.... SIP here is UDP, no? There's no connection to close for UDP. The source port for UDP doesn't matter. It's not part of the whole conversation, unless your switch cares that all communications continue to come from the source port. It's connectionless. TCP 5060 isn't even listening on our switches. So, maybe you're doing SIP over TCP? On Thu, 10 Jun 2021, Mark Wiles wrote:
VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,kvVaS9pSziMPuDe30EPcCHGNL6NIIJPndV3CtkyMITGNN_cGCOPJ3AUW9BY-HNqhC5s3LiGgqgJZgwUxdGUxpDfu0pHj3iG3NYMCaKn8wA_83b-IWu8,&typo=1> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,ltLSR8uOxno5EmVwUpGymJ9ggTdhEg824ShElI2GvkfI2yaycXvNm5o7FVRNbXCaqKzdhziKfdH676nufSvtSiFOTXmaqw8FufmlN17fy3ZX8Rsd7QSiL0X_&typo=1>
Mark, We are not using MetaSwitch. What I am saying is because we ran into this issue in the past the only thing we found to get around it was to send OPTIONS every 60 seconds. In the past we have used TCP and we actually had a lot more problems with TCP then UDP (I never dug too much into it to see why, simply moving to UDP fixed it). Does meta have an option to use an alternate port? A lot of carriers have "issues" with 5060. On Thu, Jun 10, 2021 at 9:21 AM Mark Wiles <mwiles at akabis.com> wrote:
Hi Dovid,
So just thinking about this? granted, there wasn?t SIP traffic for ?X? amount of time? but there would have been RTP? so wouldn?t that have been seen as traffic?
Hmmm? but as soon as I typed that, SIP traffic?s on one port? RTP traffic?s on another port? so even with the RTP flowing along and happy? the SIP?s another matter? right? Duh! (I?ve not had my coffee yet)
Are you saying that you?re using Metaswitch MaX UC and you?re doing a SIP OPTIONS message every 49 seconds?
I totally agree it does sound like a NAT pinhole is closing. It would seem that if that?s the case, Meta would have run into this before and had ?recommendations? to address this.
I?ll bounce your thoughts off of them.
Thanks!
Mark
*From:* Dovid Bender <dovid at telecurve.com> *Sent:* Thursday, June 10, 2021 8:47 AM *To:* Mark Wiles <mwiles at akabis.com> *Cc:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data
If I had to guess Verizon is using CGNAT and since there is no traffic for X amount of time the NAT hole for the SIP traffic is closed. When you send a re-invite at the 30 minute mark that session as far as Verizon's CGNAT devices are concerned have been closed a long time ago. You would need to send a packet to the phone or have the phone send to your switch some sort of traffic (we send SIP OPTIONS every 49 seconds) to ensure that the session stays alive.
On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mwiles at akabis.com> wrote:
If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight!
Otherwise, let me toss this out to the group for thoughts and opinions please?
We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android).
We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address).
At thirty (30) minutes into the call, the call ?dropped?. The call was re-established, and again, after thirty minutes, the call dropped.
We?re pretty sure the user was in a static position (non-mobile)? and logically *assume* they were on the same cell tower for both calls that dropped (the Verizon IP was the same).
Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone. Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port. So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876.
Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark.
Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case.
It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data. It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy? ?
Has anyone had experience with such an occurrence? or any thoughts?
Thank you!
Mark
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailma...>
49 seconds... how trusting! ;-) We use 25. Pete (it's true, but said tongue-in-cheek as I'm sure you have your data to show where the bulk of NATs expire)
On 11/06/2021, at 12:46 AM, Dovid Bender <dovid at telecurve.com> wrote:
<snip> (we send SIP OPTIONS every 49 seconds) to ensure that the session stays alive.
participants (8)
-
abalashov＠evaristesys.com -
beckman＠angryox.com -
dovid＠telecurve.com -
matthew＠corp.crocker.com -
mwiles＠akabis.com -
paul＠timmins.net -
pete＠mac.geek.nz -
ptimmins＠clearrate.com