Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-18 Thread Simon Perreault 
Le 2017-07-18 à 09:58, Colton Conor a écrit :
> I believe is you don't use SIP timers the session will close using UDP,
> whereas on TCP the session will stay active and keep the hole through
> the carriers firewall open to allow traffic to pass? 

NAT timeouts for TCP are generally much longer than for UDP, which
allows keep-alives to be much less frequent, thus saving battery life.
But that is true of any kind of NAT. Hence my question about NAT64's
relevance to this discussion.

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | sperrea...@jive.com
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-18 Thread Colton Conor 
I believe is you don't use SIP timers the session will close using UDP,
whereas on TCP the session will stay active and keep the hole through the
carriers firewall open to allow traffic to pass?

On Tue, Jul 18, 2017 at 8:54 AM, Simon Perreault 
wrote:

> Le 2017-07-18 à 09:51, Colton Conor a écrit :
> > Most all wireless carrier do not assign public facing IPv4 addresses to
> > the phone only IPv6.
>
> What is the impact of this on UDP vs TCP?
>
> --
> Simon Perreault
> Director of Engineering, Platform | Jive Communications, Inc.
> https://jive.com | +1 418 478 0989 ext. 1241 | sperrea...@jive.com
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-18 Thread Simon Perreault 
Le 2017-07-18 à 09:51, Colton Conor a écrit :
> Most all wireless carrier do not assign public facing IPv4 addresses to
> the phone only IPv6.

What is the impact of this on UDP vs TCP?

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | sperrea...@jive.com
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-18 Thread Colton Conor 
This is true. I still worry about the NAT issue when using UDP. Most all
wireless carrier do not assign public facing IPv4 addresses to the phone
only IPv6.



On Tue, Jul 18, 2017 at 3:56 AM, Nikolay Shopik 
wrote:

> On 18/07/17 00:12, jungle Boogie wrote:
> > On 16 July 2017 at 19:28, Colton Conor  wrote:
> >> Overall TCP just always
> >> seems to work, and UPD depends on the situation of the network. TCP is
> >> better for battery consumption on mobile sip applications as well.
> >>
> >
> > Knowing that TCP uses more overhead just by being TCP, is it really
> > better for mobile phone batteries?
> >
>
> Some mobile clients (on both iOS and android) allow you to use push
> notification. Thus mobile client only keep TCP connection when app is
> open. And push server keep connection/registration, when app closed only
> to wake it up when need to accept call.
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-18 Thread Colton Conor 
I do believe this to be the case. Its step two in the BroadSoft Partner
Configuration Guide Polycom UC Software VVX and Trio Phones Dated May 2017
Document Version 3.8


Step 2 Enter the Preferred Transport Type. Example:
voIpProt.server.1.transport=“TCPp referred” Set the Transport Protocol Type
to “TCP”. This is the suggested protocol to use, and prior to version
3.0.0, is required if using Busy Lamp Field (BLF).

On Mon, Jul 17, 2017 at 10:30 PM, Colton Conor 
wrote:

> I do believe this to be the case. Its step two in the attached BroadSoft
> Partner Configuration Guide Polycom UC Software VVX and Trio Phones Dated
> May 2017 Document Version 3.8
>
>
> Step 2 Enter the Preferred Transport Type. Example:
> voIpProt.server.1.transport=“TCPp referred” Set the Transport Protocol
> Type to “TCP”. This is the suggested protocol to use, and prior to version
> 3.0.0, is required if using Busy Lamp Field (BLF).
>
> On Mon, Jul 17, 2017 at 1:46 PM, Michael Bain 
> wrote:
>
>> So sounds like both Polycom and Broadsoft agree TCPpreferred aka use TCP
>> when possible is the best method, especially when using BLF. So the
>> question is why do most NOT due this. I assume there has to be some reason
>> not to.
>>
>>
>> I don't believe this is the case. TCP was recommended iff you were using
>> BLF and had large packets. (Some of the SoundPoint line had an issue with
>> UDP fragmentation, I don't believe the VVX line has this issue)
>>
>> I don't believe Polycom and BroadSoft are asserting that TCP is the best
>> method overall.
>>
>> Mike
>>
>> Sent from my iPhone
>>
>> On Jul 17, 2017, at 9:42 AM, Colton Conor  wrote:
>>
>> Pete,
>>
>> Still not quite understanding how multiple SBC's vs  primary/standby
>> fail-over is differnet? Wouldn't  primary/standby fail-over require 2
>> SBCs?
>>
>> Yes, I am referring to Polycom's  TCPpreferred setting. I just looked at
>> Polycom Admin guide, the the default is DNSnaptr not TCPpreferred.
>> However, in Broadsoft's recommended device config file it says use 
>> TCPpreferred.
>> Also in Polycom's guide, they recommend Note: Use BLF with TCPpreferred
>> transport Use this feature with TCPpreferred transport. I assume this is
>> due to UDP framentation with large BLF packets.
>>
>> So sounds like both Polycom and Broadsoft agree TCPpreferred aka use TCP
>> when possible is the best method, especially when using BLF. So the
>> question is why do most NOT due this. I assume there has to be some reason
>> not to.
>>
>>
>>
>>
>> On Mon, Jul 17, 2017 at 10:06 AM, Pete Eisengrein 
>> wrote:
>>
>>> If you have multiple SBC's (e.g. DNS SRV) then yeah, it would drop and
>>> need to re-register for both UDP and TCP. I was talking about
>>> primary/standby failover, which is more likely than a complete data center
>>> failure (**knocks on wood**). Are you referring to Polycoms for
>>> TCPpreferred? I think that's the default Polycom setting.
>>>
>>> On Mon, Jul 17, 2017 at 10:59 AM, Colton Conor 
>>> wrote:
>>>
 Pete,

 That makes sense. Lets assume a user that was registered to the west
 coast SBC using UDP. If the west coast was to fail and they were on an
 active call, its not like the call would continue and bounce over to the
 East coast right? The call would drop, and the customer would have to call
 back right?

 Assuming you have your phones register every 5 minutes or so how would
 that differ then UDP vs TCP? Are you saying UDP would instantly re-register
 to the east cost node, but TCP would wait 5 minutes to it re registers?

 I have noticed in the Broadsoft device config files provided by
 Broadsoft, that Broadsoft themselves recommends TCPpreferred: TCP is the
 preferred transport, UDP is used if TCP fails. However, I have yet to see
 any Broadsoft based providers make TCPpreferred as the standard for the
 Polycom phones. Everyone seems to leave it on the default of DNSnaptr or
 UDP only, and uses UDP signaling. The question is why aren't they following
 the Broadsoft lab tested and recommended approach?





 On Mon, Jul 17, 2017 at 8:32 AM, Pete Eisengrein 
 wrote:

> Perfect example. With an Acme SBC as a redundant pair, if (when) the
> primary fails and switches to the standby, all UDP immediately goes to the
> standby and is generally unnoticed by the end users. However, if the SIP 
> is
> over TCP in that scenario, the switch still happens but the TCP session
> must re-establish itself to the secondary SBC and therefore is an outage
> for those users until they re-register. I suppose it is possible to share
> TCP session info, but I am not aware of any SBC's that do this any
> differently (though would love to hear from the group if one exists).
>
> Somewhat related, but not really: It's since been patched but Acme
> (Oracle) had a bug at one point where it was not releasing TCP sessions
> after they were gone an

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-18 Thread Nikolay Shopik 
On 18/07/17 00:12, jungle Boogie wrote:
> On 16 July 2017 at 19:28, Colton Conor  wrote:
>> Overall TCP just always
>> seems to work, and UPD depends on the situation of the network. TCP is
>> better for battery consumption on mobile sip applications as well.
>>
> 
> Knowing that TCP uses more overhead just by being TCP, is it really
> better for mobile phone batteries?
> 

Some mobile clients (on both iOS and android) allow you to use push
notification. Thus mobile client only keep TCP connection when app is
open. And push server keep connection/registration, when app closed only
to wake it up when need to accept call.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Alex Balashov 
On Mon, Jul 17, 2017 at 10:22:20PM -0400, Ed Robbins wrote:

> John knows first hand that ACME is unable to do this seamlessly. He
> and I have spent countless hours working on issues due to Acme's
> inability to replicate TCP state.

I see. Does the marketing literature claim they can do it?

-- 
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/
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Ed Robbins 
John knows first hand that ACME is unable to do this seamlessly. He and 
I have spent countless hours working on issues due to Acme's inability 
to replicate TCP state.


Ed Robbins

On 7/17/17 7:09 PM, Alex Balashov wrote:

I am not familiar intimately with the modalities of commercial SBC
vendors' failover options these days, but it had been my understanding
that Acme Packet can, in fact, replicate TCP session state at the OS
network stack level and fail it over "relatively seamlessly". I am not
sure offhand where I learned that or whether it is accurate.

Regardless, it is certainly not a common denominator within the
industry, and is a difficult problem to solve.


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Alex Balashov 
On Mon, Jul 17, 2017 at 02:30:41PM -0500, John S. Robinson wrote:

> Although SIP registration state and SIP call state can be replicated
> over a pair of SBC's (Acme or Sonus), TCP state cannot be maintained.
> There is way to much going on at the driver level for that to be
> practical.  When switchover occurs, the TCP "transmission control"
> parameters are stale.  So, there will be a TCP RST, and the endpoints
> need to start over with the whole SYN / SYN,ACK "three-way handshake"
> drill.

I am not familiar intimately with the modalities of commercial SBC
vendors' failover options these days, but it had been my understanding
that Acme Packet can, in fact, replicate TCP session state at the OS
network stack level and fail it over "relatively seamlessly". I am not
sure offhand where I learned that or whether it is accurate. 

Regardless, it is certainly not a common denominator within the
industry, and is a difficult problem to solve. 

Moreover, speaking from an open-source vantage point, I think there is a
lot of concern that big, ambitious, capital-intensive investments in
this type of failover may not pay off if the future holds that failover
at that layer be done more commonly by "infrastructure", i.e. at the
hypervisor level. 

-- Alex

-- 
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/
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Alex Balashov 
Also, not knowing much about how mobile carrier data operates, I can't weigh 
in, but I suspect that the carrier-grade NAT and/or connection proxy 
implementations on the operator side have a great deal of influence on how well 
SIP on mobile over UDP works in practice. 

-- Alex

--
Principal, Evariste Systems LLC (www.evaristesys.com)

Sent from my Google Nexus.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Brandon Martin 

On 07/17/2017 05:12 PM, jungle Boogie wrote:

On 16 July 2017 at 19:28, Colton Conor  wrote:

Overall TCP just always
seems to work, and UPD depends on the situation of the network. TCP is
better for battery consumption on mobile sip applications as well.



Knowing that TCP uses more overhead just by being TCP, is it really
better for mobile phone batteries?



Anecdotal evidence using the built-in Android SIP client (which, while 
hilariously incapable, does support both UDP and TCP for signalling and 
is a readily-available common denominator) suggests that the less 
frequent need to refresh the registration and similar keepalive type 
mechanisms needed for UDP signalling does indeed make TCP noticeably 
better for mobile phone battery life.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread John S. Robinson 

Here is the theory behind "TCP for Mobile Phones" recommendations:

 * tcp - keep alive is supposed to happen from the Server side (SBC) 
   therefore

 * application layer can go to sleep, and firewall pin hole is kept
   open at the driver level
 * thus conserving power needed to load and wake up the application.

UAC's only need to register at the SIP application layer once every 10 
minutes or so.


In real life however, that doesn't seem to work out all that well due to 
SBC limitations (both Acme and Sonus; details on request) and limited 
support from the various phone app vendors.   Plus, if the TCP 
connection "gets lost" the risk interval of not receiving a phone call 
is just that much longer.


   John


On 7/17/2017 16:12, jungle Boogie wrote:

On 16 July 2017 at 19:28, Colton Conor  wrote:

Overall TCP just always
seems to work, and UPD depends on the situation of the network. TCP is
better for battery consumption on mobile sip applications as well.


Knowing that TCP uses more overhead just by being TCP, is it really
better for mobile phone batteries?



___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Alex Balashov 
Are low re-registration intervals and flurries of OPTIONS pings and/or CRLF 
keepalives over UDP better for mobile batteries? :-)

-- Alex

> On Jul 17, 2017, at 5:12 PM, jungle Boogie  wrote:
> 
>> On 16 July 2017 at 19:28, Colton Conor  wrote:
>> Overall TCP just always
>> seems to work, and UPD depends on the situation of the network. TCP is
>> better for battery consumption on mobile sip applications as well.
>> 
> 
> Knowing that TCP uses more overhead just by being TCP, is it really
> better for mobile phone batteries?
> 
> -- 
> ---
> inum: 883510009027723
> sip: jungleboo...@sip2sip.info
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread jungle Boogie 
On 16 July 2017 at 19:28, Colton Conor  wrote:
> Overall TCP just always
> seems to work, and UPD depends on the situation of the network. TCP is
> better for battery consumption on mobile sip applications as well.
>

Knowing that TCP uses more overhead just by being TCP, is it really
better for mobile phone batteries?

-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread John S. Robinson 
UDP remains the "weapon of choice" for sip trunking applications and for 
many subscriber applications.  However, feature-rich subscriber 
implementations frequently require SIP messages to be substantially 
larger than the (approximately) 1500 byte MTU (maximum transmission 
unit) supported in the public internet.   UDP has a mechanism for 
dealing with messages greater than MTU size, but it doesn't work 
reliably for SIP over UDP in the public internet.


When you need to go > 1500 bytes, you need to go to TCP.

Although SIP registration state and SIP call state can be replicated 
over a pair of SBC's (Acme or Sonus), TCP state cannot be maintained.  
There is way to much going on at the driver level for that to be 
practical.  When switchover occurs, the TCP "transmission control" 
parameters are stale.   So, there will be a TCP RST, and the endpoints 
need to start over with the whole SYN / SYN,ACK "three-way handshake" 
drill.


Although the subscriber device will in all likelihood need to restart 
the TCP session, the worst-case disruption will be only as long as the 
re-registration interval.  And even then, only outbound calls (toward 
the subscriber device) will be affected.  But even in that unlucky 
instance, voice mail should save the day.


The Acme "TCP session leak" was fixed several years ago  At least 
three.   Any software having that leak has been End of Support for long 
time.


If anybody would like further discussion, feel free to contact me directly.

   John S. Robinson
   jsr (at) communichanic dot com
   Communichanic Consultants, Inc.



On 7/17/2017 08:32, Pete Eisengrein wrote:
Perfect example. With an Acme SBC as a redundant pair, if (when) the 
primary fails and switches to the standby, all UDP immediately goes to 
the standby and is generally unnoticed by the end users. However, if 
the SIP is over TCP in that scenario, the switch still happens but the 
TCP session must re-establish itself to the secondary SBC and 
therefore is an outage for those users until they re-register. I 
suppose it is possible to share TCP session info, but I am not aware 
of any SBC's that do this any differently (though would love to hear 
from the group if one exists).


Somewhat related, but not really: It's since been patched but Acme 
(Oracle) had a bug at one point where it was not releasing TCP 
sessions after they were gone and you'd end up using all available 
resources (TCP ports); if that happened you'd begin blocking new 
sessions and the only workaround was a forced switchover which, of 
course, then meant a forced outage for those users.


-Pete

On Mon, Jul 17, 2017 at 9:01 AM, Colton Conor > wrote:


Thanks for the replies. I am mainly talking about using TCP for
SIP signaling for access/customer side of the network only. I
think trunk connections to carriers will stay UDP only for a long
time.

Overwhelming it seems like using TCP for signaling doesn't seem to
be a bad thing, and preferred by many. Peter, I have a question
about what you mean by "But the biggest reason I prefer UDP is for
failover/redundancy. In the event of a system failure/failover,
UDP will be in-disrupted but TCP will."

Lets assume we are using Broadsoft with an Acme Packet SBCs, and
have redundancy having one on the West coast and one on the east
cost.

Using TCP for signaling, how would this be different than using
UDP in a fail over secenario? Assume the client is closer to the
West cost node, and the West coast node rebooted or shut down due
to power failure.


Using UDP for RTP makes perfect sense. Sorry for asking the stupid
question about RTP.

On Sun, Jul 16, 2017 at 9:59 PM, Peter E mailto:peeip...@gmail.com>> wrote:

The SIP protocol already has some built in reliability
techniques built in (timers, retransmission) for which TCP is
usually used. Yes, TCP is a bit more resource intensive due to
the TCP overhead. But the biggest reason I prefer UDP is for
failover/redundancy. In the event of a system
failure/failover, UDP will be in-disrupted but TCP will. Your
TLS argument is valid, however.

RTP will always be UDP. Think about it... TCP will retransmit
when packers are lost, but in real time communication there is
no need to retransmit. While packet loss is problematic, a
retransmission of lost packets would be unexpected and cause
further quality issues.



On Jul 16, 2017, at 22:28, Colton Conor
mailto:colton.co...@gmail.com>> wrote:

I know UDP seems to be the gold standard for SIP, and is in
use by most service providers that are offering hosted voice
today. My question is why not use TCP instead of UDP for SIP
signaling?

Overall with small business clients we run into firewalls with
SIP ALGs, short UDP session time out limits, and a

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Michael Bain 
So sounds like both Polycom and Broadsoft agree TCPpreferred aka use TCP
when possible is the best method, especially when using BLF. So the
question is why do most NOT due this. I assume there has to be some reason
not to.


I don't believe this is the case. TCP was recommended iff you were using
BLF and had large packets. (Some of the SoundPoint line had an issue with
UDP fragmentation, I don't believe the VVX line has this issue)

I don't believe Polycom and BroadSoft are asserting that TCP is the best
method overall.

Mike

Sent from my iPhone

On Jul 17, 2017, at 9:42 AM, Colton Conor  wrote:

Pete,

Still not quite understanding how multiple SBC's vs  primary/standby
fail-over is differnet? Wouldn't  primary/standby fail-over require 2 SBCs?

Yes, I am referring to Polycom's  TCPpreferred setting. I just looked at
Polycom Admin guide, the the default is DNSnaptr not TCPpreferred. However,
in Broadsoft's recommended device config file it says use TCPpreferred.
Also in Polycom's guide, they recommend Note: Use BLF with TCPpreferred
transport Use this feature with TCPpreferred transport. I assume this is
due to UDP framentation with large BLF packets.

So sounds like both Polycom and Broadsoft agree TCPpreferred aka use TCP
when possible is the best method, especially when using BLF. So the
question is why do most NOT due this. I assume there has to be some reason
not to.




On Mon, Jul 17, 2017 at 10:06 AM, Pete Eisengrein 
wrote:

> If you have multiple SBC's (e.g. DNS SRV) then yeah, it would drop and
> need to re-register for both UDP and TCP. I was talking about
> primary/standby failover, which is more likely than a complete data center
> failure (**knocks on wood**). Are you referring to Polycoms for
> TCPpreferred? I think that's the default Polycom setting.
>
> On Mon, Jul 17, 2017 at 10:59 AM, Colton Conor 
> wrote:
>
>> Pete,
>>
>> That makes sense. Lets assume a user that was registered to the west
>> coast SBC using UDP. If the west coast was to fail and they were on an
>> active call, its not like the call would continue and bounce over to the
>> East coast right? The call would drop, and the customer would have to call
>> back right?
>>
>> Assuming you have your phones register every 5 minutes or so how would
>> that differ then UDP vs TCP? Are you saying UDP would instantly re-register
>> to the east cost node, but TCP would wait 5 minutes to it re registers?
>>
>> I have noticed in the Broadsoft device config files provided by
>> Broadsoft, that Broadsoft themselves recommends TCPpreferred: TCP is the
>> preferred transport, UDP is used if TCP fails. However, I have yet to see
>> any Broadsoft based providers make TCPpreferred as the standard for the
>> Polycom phones. Everyone seems to leave it on the default of DNSnaptr or
>> UDP only, and uses UDP signaling. The question is why aren't they following
>> the Broadsoft lab tested and recommended approach?
>>
>>
>>
>>
>>
>> On Mon, Jul 17, 2017 at 8:32 AM, Pete Eisengrein 
>> wrote:
>>
>>> Perfect example. With an Acme SBC as a redundant pair, if (when) the
>>> primary fails and switches to the standby, all UDP immediately goes to the
>>> standby and is generally unnoticed by the end users. However, if the SIP is
>>> over TCP in that scenario, the switch still happens but the TCP session
>>> must re-establish itself to the secondary SBC and therefore is an outage
>>> for those users until they re-register. I suppose it is possible to share
>>> TCP session info, but I am not aware of any SBC's that do this any
>>> differently (though would love to hear from the group if one exists).
>>>
>>> Somewhat related, but not really: It's since been patched but Acme
>>> (Oracle) had a bug at one point where it was not releasing TCP sessions
>>> after they were gone and you'd end up using all available resources (TCP
>>> ports); if that happened you'd begin blocking new sessions and the only
>>> workaround was a forced switchover which, of course, then meant a forced
>>> outage for those users.
>>>
>>> -Pete
>>>
>>> On Mon, Jul 17, 2017 at 9:01 AM, Colton Conor 
>>> wrote:
>>>
 Thanks for the replies. I am mainly talking about using TCP for SIP
 signaling for access/customer side of the network only. I think trunk
 connections to carriers will stay UDP only for a long time.

 Overwhelming it seems like using TCP for signaling doesn't seem to be a
 bad thing, and preferred by many. Peter, I have a question about what you
 mean by "But the biggest reason I prefer UDP is for
 failover/redundancy. In the event of a system failure/failover, UDP will be
 in-disrupted but TCP will."

 Lets assume we are using Broadsoft with an Acme Packet SBCs, and have
 redundancy having one on the West coast and one on the east cost.

 Using TCP for signaling, how would this be different than using UDP in
 a fail over secenario? Assume the client is closer to the West cost node,
 and the West coast node reb

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Colton Conor 
Pete,

Still not quite understanding how multiple SBC's vs  primary/standby
fail-over is differnet? Wouldn't  primary/standby fail-over require 2 SBCs?

Yes, I am referring to Polycom's  TCPpreferred setting. I just looked at
Polycom Admin guide, the the default is DNSnaptr not TCPpreferred. However,
in Broadsoft's recommended device config file it says use TCPpreferred.
Also in Polycom's guide, they recommend Note: Use BLF with TCPpreferred
transport Use this feature with TCPpreferred transport. I assume this is
due to UDP framentation with large BLF packets.

So sounds like both Polycom and Broadsoft agree TCPpreferred aka use TCP
when possible is the best method, especially when using BLF. So the
question is why do most NOT due this. I assume there has to be some reason
not to.




On Mon, Jul 17, 2017 at 10:06 AM, Pete Eisengrein 
wrote:

> If you have multiple SBC's (e.g. DNS SRV) then yeah, it would drop and
> need to re-register for both UDP and TCP. I was talking about
> primary/standby failover, which is more likely than a complete data center
> failure (**knocks on wood**). Are you referring to Polycoms for
> TCPpreferred? I think that's the default Polycom setting.
>
> On Mon, Jul 17, 2017 at 10:59 AM, Colton Conor 
> wrote:
>
>> Pete,
>>
>> That makes sense. Lets assume a user that was registered to the west
>> coast SBC using UDP. If the west coast was to fail and they were on an
>> active call, its not like the call would continue and bounce over to the
>> East coast right? The call would drop, and the customer would have to call
>> back right?
>>
>> Assuming you have your phones register every 5 minutes or so how would
>> that differ then UDP vs TCP? Are you saying UDP would instantly re-register
>> to the east cost node, but TCP would wait 5 minutes to it re registers?
>>
>> I have noticed in the Broadsoft device config files provided by
>> Broadsoft, that Broadsoft themselves recommends TCPpreferred: TCP is the
>> preferred transport, UDP is used if TCP fails. However, I have yet to see
>> any Broadsoft based providers make TCPpreferred as the standard for the
>> Polycom phones. Everyone seems to leave it on the default of DNSnaptr or
>> UDP only, and uses UDP signaling. The question is why aren't they following
>> the Broadsoft lab tested and recommended approach?
>>
>>
>>
>>
>>
>> On Mon, Jul 17, 2017 at 8:32 AM, Pete Eisengrein 
>> wrote:
>>
>>> Perfect example. With an Acme SBC as a redundant pair, if (when) the
>>> primary fails and switches to the standby, all UDP immediately goes to the
>>> standby and is generally unnoticed by the end users. However, if the SIP is
>>> over TCP in that scenario, the switch still happens but the TCP session
>>> must re-establish itself to the secondary SBC and therefore is an outage
>>> for those users until they re-register. I suppose it is possible to share
>>> TCP session info, but I am not aware of any SBC's that do this any
>>> differently (though would love to hear from the group if one exists).
>>>
>>> Somewhat related, but not really: It's since been patched but Acme
>>> (Oracle) had a bug at one point where it was not releasing TCP sessions
>>> after they were gone and you'd end up using all available resources (TCP
>>> ports); if that happened you'd begin blocking new sessions and the only
>>> workaround was a forced switchover which, of course, then meant a forced
>>> outage for those users.
>>>
>>> -Pete
>>>
>>> On Mon, Jul 17, 2017 at 9:01 AM, Colton Conor 
>>> wrote:
>>>
 Thanks for the replies. I am mainly talking about using TCP for SIP
 signaling for access/customer side of the network only. I think trunk
 connections to carriers will stay UDP only for a long time.

 Overwhelming it seems like using TCP for signaling doesn't seem to be a
 bad thing, and preferred by many. Peter, I have a question about what you
 mean by "But the biggest reason I prefer UDP is for
 failover/redundancy. In the event of a system failure/failover, UDP will be
 in-disrupted but TCP will."

 Lets assume we are using Broadsoft with an Acme Packet SBCs, and have
 redundancy having one on the West coast and one on the east cost.

 Using TCP for signaling, how would this be different than using UDP in
 a fail over secenario? Assume the client is closer to the West cost node,
 and the West coast node rebooted or shut down due to power failure.


 Using UDP for RTP makes perfect sense. Sorry for asking the stupid
 question about RTP.

 On Sun, Jul 16, 2017 at 9:59 PM, Peter E  wrote:

> The SIP protocol already has some built in reliability techniques
> built in (timers, retransmission) for which TCP is usually used. Yes, TCP
> is a bit more resource intensive due to the TCP overhead. But the biggest
> reason I prefer UDP is for failover/redundancy. In the event of a system
> failure/failover, UDP will be in-disrupted but TCP will. Your TLS argument
>>

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Pete Eisengrein 
If you have multiple SBC's (e.g. DNS SRV) then yeah, it would drop and need
to re-register for both UDP and TCP. I was talking about primary/standby
failover, which is more likely than a complete data center failure
(**knocks on wood**). Are you referring to Polycoms for TCPpreferred? I
think that's the default Polycom setting.

On Mon, Jul 17, 2017 at 10:59 AM, Colton Conor 
wrote:

> Pete,
>
> That makes sense. Lets assume a user that was registered to the west coast
> SBC using UDP. If the west coast was to fail and they were on an active
> call, its not like the call would continue and bounce over to the East
> coast right? The call would drop, and the customer would have to call back
> right?
>
> Assuming you have your phones register every 5 minutes or so how would
> that differ then UDP vs TCP? Are you saying UDP would instantly re-register
> to the east cost node, but TCP would wait 5 minutes to it re registers?
>
> I have noticed in the Broadsoft device config files provided by Broadsoft,
> that Broadsoft themselves recommends TCPpreferred: TCP is the preferred
> transport, UDP is used if TCP fails. However, I have yet to see any
> Broadsoft based providers make TCPpreferred as the standard for the Polycom
> phones. Everyone seems to leave it on the default of DNSnaptr or UDP only,
> and uses UDP signaling. The question is why aren't they following the
> Broadsoft lab tested and recommended approach?
>
>
>
>
>
> On Mon, Jul 17, 2017 at 8:32 AM, Pete Eisengrein 
> wrote:
>
>> Perfect example. With an Acme SBC as a redundant pair, if (when) the
>> primary fails and switches to the standby, all UDP immediately goes to the
>> standby and is generally unnoticed by the end users. However, if the SIP is
>> over TCP in that scenario, the switch still happens but the TCP session
>> must re-establish itself to the secondary SBC and therefore is an outage
>> for those users until they re-register. I suppose it is possible to share
>> TCP session info, but I am not aware of any SBC's that do this any
>> differently (though would love to hear from the group if one exists).
>>
>> Somewhat related, but not really: It's since been patched but Acme
>> (Oracle) had a bug at one point where it was not releasing TCP sessions
>> after they were gone and you'd end up using all available resources (TCP
>> ports); if that happened you'd begin blocking new sessions and the only
>> workaround was a forced switchover which, of course, then meant a forced
>> outage for those users.
>>
>> -Pete
>>
>> On Mon, Jul 17, 2017 at 9:01 AM, Colton Conor 
>> wrote:
>>
>>> Thanks for the replies. I am mainly talking about using TCP for SIP
>>> signaling for access/customer side of the network only. I think trunk
>>> connections to carriers will stay UDP only for a long time.
>>>
>>> Overwhelming it seems like using TCP for signaling doesn't seem to be a
>>> bad thing, and preferred by many. Peter, I have a question about what you
>>> mean by "But the biggest reason I prefer UDP is for
>>> failover/redundancy. In the event of a system failure/failover, UDP will be
>>> in-disrupted but TCP will."
>>>
>>> Lets assume we are using Broadsoft with an Acme Packet SBCs, and have
>>> redundancy having one on the West coast and one on the east cost.
>>>
>>> Using TCP for signaling, how would this be different than using UDP in a
>>> fail over secenario? Assume the client is closer to the West cost node, and
>>> the West coast node rebooted or shut down due to power failure.
>>>
>>>
>>> Using UDP for RTP makes perfect sense. Sorry for asking the stupid
>>> question about RTP.
>>>
>>> On Sun, Jul 16, 2017 at 9:59 PM, Peter E  wrote:
>>>
 The SIP protocol already has some built in reliability techniques built
 in (timers, retransmission) for which TCP is usually used. Yes, TCP is a
 bit more resource intensive due to the TCP overhead. But the biggest reason
 I prefer UDP is for failover/redundancy. In the event of a system
 failure/failover, UDP will be in-disrupted but TCP will. Your TLS argument
 is valid, however.

 RTP will always be UDP. Think about it... TCP will retransmit when
 packers are lost, but in real time communication there is no need to
 retransmit. While packet loss is problematic, a retransmission of lost
 packets would be unexpected and cause further quality issues.



 On Jul 16, 2017, at 22:28, Colton Conor  wrote:

 I know UDP seems to be the gold standard for SIP, and is in use by most
 service providers that are offering hosted voice today. My question is why
 not use TCP instead of UDP for SIP signaling?

 Overall with small business clients we run into firewalls with SIP
 ALGs, short UDP session time out limits, and all sorts of connectivity
 issues with UDP. Some small business routers and modems have built in SIP
 ALGs that can't be disabled at all. The second we switch to TCP for
 signaling most of the issues go away for

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Tim Bray 


On 17/07/17 03:28, Colton Conor wrote:
> With more providers switching to encryption using TLS which uses TCP,
> is there any need for us UDP for signaling anymore? Assuming most IP
> phones from Polycom, Yealink, and Cisco support TCP why not use it? Is
> it more resouce intensive on the SBCs?

No harm keeping UDP.

It is up to service providers what they want to use.  And what works for
their customers.

I'm in favour of more TLS - it stops ALGs for sure.

>
> What about on the media side? Does the RTP use UDP or TCP? If it uses
> UDP can TCP be used? What about for encryption like SRTP? Is SRTP TCP
> or UDP?

Normal SRTP is UDP.

No reason not to run RTP over TCP. It's an option to configure in Snom
phones.   I think MS Lync might use it.

If you get packet loss, retransmits would kill delay the call.   Depends
on packetloss vs round trip time.


Tim
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Colton Conor 
Pete,

That makes sense. Lets assume a user that was registered to the west coast
SBC using UDP. If the west coast was to fail and they were on an active
call, its not like the call would continue and bounce over to the East
coast right? The call would drop, and the customer would have to call back
right?

Assuming you have your phones register every 5 minutes or so how would that
differ then UDP vs TCP? Are you saying UDP would instantly re-register to
the east cost node, but TCP would wait 5 minutes to it re registers?

I have noticed in the Broadsoft device config files provided by Broadsoft,
that Broadsoft themselves recommends TCPpreferred: TCP is the preferred
transport, UDP is used if TCP fails. However, I have yet to see any
Broadsoft based providers make TCPpreferred as the standard for the Polycom
phones. Everyone seems to leave it on the default of DNSnaptr or UDP only,
and uses UDP signaling. The question is why aren't they following the
Broadsoft lab tested and recommended approach?





On Mon, Jul 17, 2017 at 8:32 AM, Pete Eisengrein  wrote:

> Perfect example. With an Acme SBC as a redundant pair, if (when) the
> primary fails and switches to the standby, all UDP immediately goes to the
> standby and is generally unnoticed by the end users. However, if the SIP is
> over TCP in that scenario, the switch still happens but the TCP session
> must re-establish itself to the secondary SBC and therefore is an outage
> for those users until they re-register. I suppose it is possible to share
> TCP session info, but I am not aware of any SBC's that do this any
> differently (though would love to hear from the group if one exists).
>
> Somewhat related, but not really: It's since been patched but Acme
> (Oracle) had a bug at one point where it was not releasing TCP sessions
> after they were gone and you'd end up using all available resources (TCP
> ports); if that happened you'd begin blocking new sessions and the only
> workaround was a forced switchover which, of course, then meant a forced
> outage for those users.
>
> -Pete
>
> On Mon, Jul 17, 2017 at 9:01 AM, Colton Conor 
> wrote:
>
>> Thanks for the replies. I am mainly talking about using TCP for SIP
>> signaling for access/customer side of the network only. I think trunk
>> connections to carriers will stay UDP only for a long time.
>>
>> Overwhelming it seems like using TCP for signaling doesn't seem to be a
>> bad thing, and preferred by many. Peter, I have a question about what you
>> mean by "But the biggest reason I prefer UDP is for failover/redundancy.
>> In the event of a system failure/failover, UDP will be in-disrupted but TCP
>> will."
>>
>> Lets assume we are using Broadsoft with an Acme Packet SBCs, and have
>> redundancy having one on the West coast and one on the east cost.
>>
>> Using TCP for signaling, how would this be different than using UDP in a
>> fail over secenario? Assume the client is closer to the West cost node, and
>> the West coast node rebooted or shut down due to power failure.
>>
>>
>> Using UDP for RTP makes perfect sense. Sorry for asking the stupid
>> question about RTP.
>>
>> On Sun, Jul 16, 2017 at 9:59 PM, Peter E  wrote:
>>
>>> The SIP protocol already has some built in reliability techniques built
>>> in (timers, retransmission) for which TCP is usually used. Yes, TCP is a
>>> bit more resource intensive due to the TCP overhead. But the biggest reason
>>> I prefer UDP is for failover/redundancy. In the event of a system
>>> failure/failover, UDP will be in-disrupted but TCP will. Your TLS argument
>>> is valid, however.
>>>
>>> RTP will always be UDP. Think about it... TCP will retransmit when
>>> packers are lost, but in real time communication there is no need to
>>> retransmit. While packet loss is problematic, a retransmission of lost
>>> packets would be unexpected and cause further quality issues.
>>>
>>>
>>>
>>> On Jul 16, 2017, at 22:28, Colton Conor  wrote:
>>>
>>> I know UDP seems to be the gold standard for SIP, and is in use by most
>>> service providers that are offering hosted voice today. My question is why
>>> not use TCP instead of UDP for SIP signaling?
>>>
>>> Overall with small business clients we run into firewalls with SIP ALGs,
>>> short UDP session time out limits, and all sorts of connectivity issues
>>> with UDP. Some small business routers and modems have built in SIP ALGs
>>> that can't be disabled at all. The second we switch to TCP for signaling
>>> most of the issues go away for our hosted voice customers. Overall TCP just
>>> always seems to work, and UPD depends on the situation of the network. TCP
>>> is better for battery consumption on mobile sip applications as well.
>>>
>>> With more providers switching to encryption using TLS which uses TCP, is
>>> there any need for us UDP for signaling anymore? Assuming most IP phones
>>> from Polycom, Yealink, and Cisco support TCP why not use it? Is it more
>>> resouce intensive on the SBCs?
>>>
>>> What about on the media s

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Pete Eisengrein 
Perfect example. With an Acme SBC as a redundant pair, if (when) the
primary fails and switches to the standby, all UDP immediately goes to the
standby and is generally unnoticed by the end users. However, if the SIP is
over TCP in that scenario, the switch still happens but the TCP session
must re-establish itself to the secondary SBC and therefore is an outage
for those users until they re-register. I suppose it is possible to share
TCP session info, but I am not aware of any SBC's that do this any
differently (though would love to hear from the group if one exists).

Somewhat related, but not really: It's since been patched but Acme (Oracle)
had a bug at one point where it was not releasing TCP sessions after they
were gone and you'd end up using all available resources (TCP ports); if
that happened you'd begin blocking new sessions and the only workaround was
a forced switchover which, of course, then meant a forced outage for those
users.

-Pete

On Mon, Jul 17, 2017 at 9:01 AM, Colton Conor 
wrote:

> Thanks for the replies. I am mainly talking about using TCP for SIP
> signaling for access/customer side of the network only. I think trunk
> connections to carriers will stay UDP only for a long time.
>
> Overwhelming it seems like using TCP for signaling doesn't seem to be a
> bad thing, and preferred by many. Peter, I have a question about what you
> mean by "But the biggest reason I prefer UDP is for failover/redundancy.
> In the event of a system failure/failover, UDP will be in-disrupted but TCP
> will."
>
> Lets assume we are using Broadsoft with an Acme Packet SBCs, and have
> redundancy having one on the West coast and one on the east cost.
>
> Using TCP for signaling, how would this be different than using UDP in a
> fail over secenario? Assume the client is closer to the West cost node, and
> the West coast node rebooted or shut down due to power failure.
>
>
> Using UDP for RTP makes perfect sense. Sorry for asking the stupid
> question about RTP.
>
> On Sun, Jul 16, 2017 at 9:59 PM, Peter E  wrote:
>
>> The SIP protocol already has some built in reliability techniques built
>> in (timers, retransmission) for which TCP is usually used. Yes, TCP is a
>> bit more resource intensive due to the TCP overhead. But the biggest reason
>> I prefer UDP is for failover/redundancy. In the event of a system
>> failure/failover, UDP will be in-disrupted but TCP will. Your TLS argument
>> is valid, however.
>>
>> RTP will always be UDP. Think about it... TCP will retransmit when
>> packers are lost, but in real time communication there is no need to
>> retransmit. While packet loss is problematic, a retransmission of lost
>> packets would be unexpected and cause further quality issues.
>>
>>
>>
>> On Jul 16, 2017, at 22:28, Colton Conor  wrote:
>>
>> I know UDP seems to be the gold standard for SIP, and is in use by most
>> service providers that are offering hosted voice today. My question is why
>> not use TCP instead of UDP for SIP signaling?
>>
>> Overall with small business clients we run into firewalls with SIP ALGs,
>> short UDP session time out limits, and all sorts of connectivity issues
>> with UDP. Some small business routers and modems have built in SIP ALGs
>> that can't be disabled at all. The second we switch to TCP for signaling
>> most of the issues go away for our hosted voice customers. Overall TCP just
>> always seems to work, and UPD depends on the situation of the network. TCP
>> is better for battery consumption on mobile sip applications as well.
>>
>> With more providers switching to encryption using TLS which uses TCP, is
>> there any need for us UDP for signaling anymore? Assuming most IP phones
>> from Polycom, Yealink, and Cisco support TCP why not use it? Is it more
>> resouce intensive on the SBCs?
>>
>> What about on the media side? Does the RTP use UDP or TCP? If it uses UDP
>> can TCP be used? What about for encryption like SRTP? Is SRTP TCP or UDP?
>>
>>
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Colton Conor 
Thanks for the replies. I am mainly talking about using TCP for SIP
signaling for access/customer side of the network only. I think trunk
connections to carriers will stay UDP only for a long time.

Overwhelming it seems like using TCP for signaling doesn't seem to be a bad
thing, and preferred by many. Peter, I have a question about what you mean
by "But the biggest reason I prefer UDP is for failover/redundancy. In the
event of a system failure/failover, UDP will be in-disrupted but TCP will."

Lets assume we are using Broadsoft with an Acme Packet SBCs, and have
redundancy having one on the West coast and one on the east cost.

Using TCP for signaling, how would this be different than using UDP in a
fail over secenario? Assume the client is closer to the West cost node, and
the West coast node rebooted or shut down due to power failure.


Using UDP for RTP makes perfect sense. Sorry for asking the stupid question
about RTP.

On Sun, Jul 16, 2017 at 9:59 PM, Peter E  wrote:

> The SIP protocol already has some built in reliability techniques built in
> (timers, retransmission) for which TCP is usually used. Yes, TCP is a bit
> more resource intensive due to the TCP overhead. But the biggest reason I
> prefer UDP is for failover/redundancy. In the event of a system
> failure/failover, UDP will be in-disrupted but TCP will. Your TLS argument
> is valid, however.
>
> RTP will always be UDP. Think about it... TCP will retransmit when packers
> are lost, but in real time communication there is no need to retransmit.
> While packet loss is problematic, a retransmission of lost packets would be
> unexpected and cause further quality issues.
>
>
>
> On Jul 16, 2017, at 22:28, Colton Conor  wrote:
>
> I know UDP seems to be the gold standard for SIP, and is in use by most
> service providers that are offering hosted voice today. My question is why
> not use TCP instead of UDP for SIP signaling?
>
> Overall with small business clients we run into firewalls with SIP ALGs,
> short UDP session time out limits, and all sorts of connectivity issues
> with UDP. Some small business routers and modems have built in SIP ALGs
> that can't be disabled at all. The second we switch to TCP for signaling
> most of the issues go away for our hosted voice customers. Overall TCP just
> always seems to work, and UPD depends on the situation of the network. TCP
> is better for battery consumption on mobile sip applications as well.
>
> With more providers switching to encryption using TLS which uses TCP, is
> there any need for us UDP for signaling anymore? Assuming most IP phones
> from Polycom, Yealink, and Cisco support TCP why not use it? Is it more
> resouce intensive on the SBCs?
>
> What about on the media side? Does the RTP use UDP or TCP? If it uses UDP
> can TCP be used? What about for encryption like SRTP? Is SRTP TCP or UDP?
>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Nikolay Shopik 
On 17/07/17 12:22, Alex Balashov wrote:
> On Mon, Jul 17, 2017 at 12:19:47PM +0300, Nikolay Shopik wrote:
> 
>> - protect you from async routing of packets (we had issue where we
>> protect TCP stream with VPN tunnel, but at some point something broke
>> at farend side and packets keep flowing around tunnel and UDP gladly
>> accept them since there no session establishing)
> 
> Assuming that firewall rules make this possible, wouldn't this occur
> with TCP as well, by way of the client or server simply opening a new
> TCP connection next time one needs to contact the other?
> 

Our case was with multi homing, TCP won't accept SYN.ACK response on
different interface since its binding to IP when sending SYN.
Unfortunately I don't remember all details now.

So yeah TCP doesn't protect from all async cases but helps in some.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Alex Balashov 
On Mon, Jul 17, 2017 at 12:19:47PM +0300, Nikolay Shopik wrote:

> - protect you from async routing of packets (we had issue where we
> protect TCP stream with VPN tunnel, but at some point something broke
> at farend side and packets keep flowing around tunnel and UDP gladly
> accept them since there no session establishing)

Assuming that firewall rules make this possible, wouldn't this occur
with TCP as well, by way of the client or server simply opening a new
TCP connection next time one needs to contact the other?

-- 
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/
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Nikolay Shopik 
On 17/07/17 05:28, Colton Conor wrote:
> I know UDP seems to be the gold standard for SIP, and is in use by most
> service providers that are offering hosted voice today. My question is why
> not use TCP instead of UDP for SIP signaling?
> 
> Overall with small business clients we run into firewalls with SIP ALGs,
> short UDP session time out limits, and all sorts of connectivity issues
> with UDP. Some small business routers and modems have built in SIP ALGs
> that can't be disabled at all. The second we switch to TCP for signaling
> most of the issues go away for our hosted voice customers. Overall TCP just
> always seems to work, and UPD depends on the situation of the network. TCP
> is better for battery consumption on mobile sip applications as well.
> 
> With more providers switching to encryption using TLS which uses TCP, is
> there any need for us UDP for signaling anymore? Assuming most IP phones
> from Polycom, Yealink, and Cisco support TCP why not use it? Is it more
> resouce intensive on the SBCs?
> 
> What about on the media side? Does the RTP use UDP or TCP? If it uses UDP
> can TCP be used? What about for encryption like SRTP? Is SRTP TCP or UDP?

We switched to TCP 2 years ago since we need TLS. And experience with
end-points was mostly positive. Not all of them quite same but its much
improvement over UDP for us.

pros
- Better timeouts if you consider default UDP (where its 32s)
- Server which reset your registration usualy send tcp.rst, which allow
client to immediately start try re-register (not all of them do that)
- protect you from async routing of packets (we had issue where we
protect TCP stream with VPN tunnel, but at some point something broke at
farend side and packets keep flowing around tunnel and UDP gladly accept
them since there no session establishing)

cons
- Its still TCP and putting it on heavy loaded trunk will cause Head of
Line blocking from time to time. Same applies to end-points if there is
packet lost, but its negligible.

RTP will still use UDP there is no need for TCP there it will make it
just worse with its HoL problem.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Alex Balashov 
On Mon, Jul 17, 2017 at 12:06:59PM +0300, Nikolay Shopik wrote:

> On 17/07/17 06:08, Alex Balashov wrote:
> > 2. WebRTC and concomitant/similar technologies and feature sets, which
> > use TCP or TCP-encapsulated transports;
> 
> I belive WebRTC use SCTPoverDTLSoverUDP

WebRTC does not mandate a specific signalling technology or transport.

SIP over WebSocket (and therefore TCP) is common in SIP implementations.
It is certainly not the only way to do whatever it is that people
usually envision when they say "WebRTC", which is in just a collection
of browser media APIs and very loosely-defined standards for the
networking portion.

-- Alex

-- 
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/
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-17 Thread Nikolay Shopik 
On 17/07/17 06:08, Alex Balashov wrote:
> 2. WebRTC and concomitant/similar technologies and feature sets, which
> use TCP or TCP-encapsulated transports;

I belive WebRTC use SCTPoverDTLSoverUDP
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-16 Thread Alex Balashov 
The use of TCP on the access/customer side of the network is increasing
because of:

1. Growing SIP message sizes and headers, and the UDP fragmentation it
engenders; 

2. WebRTC and concomitant/similar technologies and feature sets, which
use TCP or TCP-encapsulated transports;

3. Growing requirements of TLS/crypto, especially at the "last mile".

That said, TCP is certainly more resource-intensive, just by
definition. There is a lot of connection state to be held by the OS's
network stack. However, this isn't as relevant a consideration as it was
in the days when the guidance about the resource trade-offs was written,
due to the increase in RAM and processing power. 

And, as Peter E. said, there is the problem of replicating / holding
onto TCP state through failover, which has not been satisfactorily
solved at a reasonably universal level.

UDP continues to hold sway not only because of custom, habit and
inertia, but also because of its innate simplicity and resource
economies at large scales of message processing.

It's not necessarily an inappropriate business decision in 2017 to
switch your customers 100% to TCP. It depends on what kind of
business-level trade-offs you are willing to make with regard to
infrastructure, resource consumption and availability. UDP will probably
continue to obtain inside the service provider network core and in
inter-carrier, strictly Class 4 interconnects/trunk interfaces.

-- Alex

-- 
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/
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-16 Thread Brandon Martin 

On 07/16/2017 10:28 PM, Colton Conor wrote:

I know UDP seems to be the gold standard for SIP, and is in use by most
service providers that are offering hosted voice today. My question is
why not use TCP instead of UDP for SIP signaling?

...


My (extremely small, internal use only) deployment uses TCP for 
signalling wherever possible.  As you said, it seems to be more reliable 
and allows the use of TLS.  I can't speak to the implications of a large 
scale deployment.



What about on the media side? Does the RTP use UDP or TCP? If it uses
UDP can TCP be used? What about for encryption like SRTP? Is SRTP TCP or
UDP?


It uses UDP, and that's intentional.  The back-off and repeat 
characteristics of TCP, while useful for reliable transmissions of bulk 
data with no real-time requirements, are detrimental to real-time, 
low-latency communication media.  A single lost packet would cause a 
huge hole in the media during back-off and retransmit only to deliver 
data that's old and has to be dropped by the consumer to restore the 
real-time synchronization with the sender.  It's far better to just 
accept dropped media and either have a short hole in the media or 
attempt to conceal it somehow which many modern CODECs support.  Some 
also support using forward error correction and data timespace 
scrambling to completely reconstruct the original data when there's a 
small amount of packet loss at the cost of slightly higher end-to-end 
latency.


--
Brandon Martin
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TCP Signaling for SIP Signaling

2017-07-16 Thread Peter E 
The SIP protocol already has some built in reliability techniques built in 
(timers, retransmission) for which TCP is usually used. Yes, TCP is a bit more 
resource intensive due to the TCP overhead. But the biggest reason I prefer UDP 
is for failover/redundancy. In the event of a system failure/failover, UDP will 
be in-disrupted but TCP will. Your TLS argument is valid, however.

RTP will always be UDP. Think about it... TCP will retransmit when packers are 
lost, but in real time communication there is no need to retransmit. While 
packet loss is problematic, a retransmission of lost packets would be 
unexpected and cause further quality issues. 



On Jul 16, 2017, at 22:28, Colton Conor  wrote:

I know UDP seems to be the gold standard for SIP, and is in use by most service 
providers that are offering hosted voice today. My question is why not use TCP 
instead of UDP for SIP signaling?

Overall with small business clients we run into firewalls with SIP ALGs, short 
UDP session time out limits, and all sorts of connectivity issues with UDP. 
Some small business routers and modems have built in SIP ALGs that can't be 
disabled at all. The second we switch to TCP for signaling most of the issues 
go away for our hosted voice customers. Overall TCP just always seems to work, 
and UPD depends on the situation of the network. TCP is better for battery 
consumption on mobile sip applications as well. 

With more providers switching to encryption using TLS which uses TCP, is there 
any need for us UDP for signaling anymore? Assuming most IP phones from 
Polycom, Yealink, and Cisco support TCP why not use it? Is it more resouce 
intensive on the SBCs? 

What about on the media side? Does the RTP use UDP or TCP? If it uses UDP can 
TCP be used? What about for encryption like SRTP? Is SRTP TCP or UDP?


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops