Re: [VoiceOps] TCP Signaling for SIP Signaling

[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

[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

[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

[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] Yealink's new "E2" hardware variants

[Nikolay Shopik]

E2 have more memory and probably better cpu. For example t19 wont accept
sha256 signed certificates, because of memory constrains or at least
that what I've been told from yealink.

On 03/11/15 01:58, Pete Mundy wrote:
> Hi list,
> 
> Does anyone here have any information they can share on what the difference 
> is with the new 'E2' variants of some of Yealink's phones?
> 
> We have a reasonable number of YL phones in our fleet, and a few months back 
> we noticed our new stock was starting to be supplied as SIP-T21P E2s after 
> SIP-T21P went EOL with our country's distributor (which was not long at all 
> after SIP-T20P went EOL!).
> 
> We now have SIP-T19P E2s arriving new too (instead of SIP-T19 prior).
> 
> These new E2 variants use different hardware identifiers and run different 
> version numbers. They look to use a different build of a the same source 
> code. They don't appear to accept downloaded configurations from the non-E2 
> variants.
> 
> Just wondering if anyone in the know can share what the change is under the 
> good?
> 
> Only for interest's sake really. I've done a bit of Googling, but haven't 
> determined much other than that TI Titan and Aries seem to be used in other 
> products. I'm guessing it's perhaps a change of CPU platform or some other 
> chipset change.
> 
> Pete
> 
> http://www.yealink.com/product_list.aspx?ProductsCateID=1301=1298=1301=1301_Id=1301=2
> http://www.yealink.com/product_info.aspx?ProductsCateID=1275=1254=1275=1275_Id=1275=3
> http://www.yealink.com/product_info.aspx?ProductsCateID=1255=1254=1255=1255_Id=1255=3
> ___
> 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] Lack of Quality Industry-wide

[Nikolay Shopik]

Maybe its show lack of quality/affordable products in this area
(monitoring voip)?

On 6/10/2015 18:27, Peter Beckman wrote:
> In the last 3 months I've been consistently frustrated by my carriers.
> 
> "3-4 minutes is acceptable delay for delivery of SMS messages."
> 
> "Our termination change now throws 504s instead of 503s 20-50% of the
>  time and adds 2-3 seconds of delay to your call attempts. We didn't
>  notice, and though you did, it's been 3 days and we haven't fixed it.
>  Sorry!"
> 
> "There was an outage? Works for me now!"
> 
> "Someone upstream is intentionally dropping SMS messages. But we can't
>  say who it is, and we can't get them to fix it because they aren't our
>  carrier."
> 
> Does the industry just suck at knowing when their stuff is broken, or only
> react when enough customers complain? Do carriers simply not instrument,
> monitor or graph metrics of their operations and proactively monitor and
> fix issues?
> 
> My Thresholds:
> * SMS delivery end-to-end: Under 10 seconds
> * 503 Route Advance: Under 1 second
> * Response/Notice to termination/API/origination/server outage: 20
> minutes
> * Fix a major issue (or provide a fix timeline): 3 days
> 
> Too many times in the last few months _I_ have been the canary in the
> carrier's coal mine bringing attention to places where their operations are
> broken or delayed. And even then, unless I escalate to management (like CEO
> level), things move at the speed of a sloth. Most of the time it seems I
> monitor my carrier's infrastructure more closely than they do.
> 
> I hope and dream of the unicorn carrier -- such great operational awareness
> and execution that it doesn't matter how great their customer service is,
> I'll never have to talk to them.
> 
> Beckman
> ---
> Peter Beckman  Internet Guy
> beck...@angryox.com http://www.angryox.com/
> ---
> ___
> 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] SIP HD Peering with Wireless Carriers

[Nikolay Shopik]

Iirc its g722.2 which is completely different from g722. 


 On 13 февр. 2015 г., at 17:11, Colton Conor colton.co...@gmail.com wrote:
 
 Are these carriers going to enable HD G722 SIP peering to their wireless 
 counterparts networks?

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