headers
Otmar Lendl | 1 Aug 2006 08:28
Picon
Favicon

Re: Voice codecs


Yes, that makes a lot of sense.

On 2006/07/31 23:07, Daryl Malas <daryl@...> wrote:
> I agree with Geoff's statement below.
> 
> On Mon, 2006-07-31 at 14:52 -0400, Geoff Devine wrote:
> > That sounds good to me.  
> > 
> > I'd point out that different federations are likely to have different
> > ideas about what makes up the "minimal codec".  In broadband-oriented
> > federations, that would likely be G.711.  In cellular-centric
> > federations that are converging to IP transport, it's more likely to be
> > their native client compression codec.  If eBay created one based on
> > Skype, it could very well be iLBC.
> > 
> > I think we all agree that transcoding is something we want to avoid but
> > we need to come up with an architecture that takes it into account. 
> > 
> > Geoff
> > 
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@...] 
> > Sent: Monday, July 31, 2006 2:39 PM
> > To: Geoff Devine; 'Livingood, Jason'; speermint@...
> > Cc: 'Greg Herlein'; 'Ed Okerson'; 'Lipford,Mark A [CTO]'; 'Klaus
> > Darilion'; 'Henry Sinnreich'
> > Subject: RE: [Speermint] Voice codecs
> > 
> > Okay, makes sense.  So, maybe it's more like, the federation agrees on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cullen Jennings | 1 Aug 2006 09:12
Picon
Favicon
Gravatar

Re: Just submitted draft-mahy-speermint-direct-peering-00


On Jul 21, 2006, at 1:32 AM, Klaus Darilion wrote:

> Hi Rohan!
>
> Sorry for jumping in late - I had long holidays. I have a few  
> concerns about the TLS stuff:
>
>
>> 4.1.6  Setup TLS connection
>>    Once a transport, port, and address are found, the initiating peer
>>    will open or find a reusable TLS connection to the peer.  The
>>    initiating provider MUST verify the server certificate which  
>> SHOULD
>>    be rooted in a well-known certificate authority.  The initiating
>
> How should the validation be done? You describe how the client  
> validation works, but not the server validation.
>
>>    provider MUST be prepared to provide a TLS client certificate upon
>>    request during the TLS handshake.  The client certificate MUST
>>    contain a DNS or URI choice type in the subjectAltName which
>>    corresponds to the domain asserted in the host production of  
>> the From
>>    header URI.  The certificate SHOULD be valid and rooted in a well-

Hmm - I missed this when I read Rohan's draft - nice catch. I think  
that if you use client certs, you would want to do it more like what  
is described in draft-mahy-sip-connect-reuse. My initial reaction  
would be don't use client certs in the first stab at this and add
(Continue reading)

Permalink | Reply | 1 comment |
headers
Cullen Jennings | 1 Aug 2006 09:03
Picon
Favicon
Gravatar

Re: TLS for peering (was RE:Comments (RE:requirementsdraftsubmitted))


End to end certificates seem like they would be used with the S/MIME  
portion of SIP. I don't think anyone has been suggesting one should  
mandate that. I don't think we should confuse the TLS stuff with end  
to end security.

With the TLS stuff you only compare the name in the certificate to  
the next hop that you are routing too. I think this is fairly well  
defined and lots of people have implemented that part of 3261. (I  
agree there are problems with implementing sips but again, I don't  
think anyone is talking about using sips here).

I will note that many enterprises today peer IM with folks like MSN/ 
Yahoo/AOL using SIP and it is mostly done over TLS.

Anyways, it sounds like we are coming to some agreement for the type  
of TLS thing we are interested - which is TLS transport and not end  
to end and not sips, RFC 3261 is adequately specified and implementable.

Cullen

On Jul 27, 2006, at 6:37 AM, Lee, Yiu wrote:

> Hi Klaus,
>
> Sorry for mis-understanding your previous post. I agree that using the
> domain for the end-to-end certification is broken in federation.
>
> Thanks for the clarification.
>
(Continue reading)

Permalink | Reply | 503 comments |
headers
Cullen Jennings | 1 Aug 2006 09:03
Picon
Favicon
Gravatar

Re: TLs performance


Klaus, first of all thank you for producing some real results we can  
discuss.  Just to validate some of your results - this is not the  
first time I have seen performance results where TLS (or more  
specifically TCP) has better performance that UDP. I have seen this  
on other products too and when I think about it, it is not that  
surprising.

Cullen

On Jul 24, 2006, at 10:59 AM, Klaus Darilion wrote:

> Hi!
>
> I made some tests with sipp+openser:
>
> scenario:
>
> UAC <-TLS-≥ openser <-TLS-≥ UAS (all of them got its own 2xP3  
> 1,26GHz machine, linked with 100MBit). Simple forwarding  
> configuration (like a loadbalancer), no DNS lookups or DB queries.
>
> UDP: ~620 cps
> TLS: ~680 cps (single TLS connection)
>
> cps=calls per second = INVITE-180-200-OK-ACK-BYE-200
>
> I think TLS performs better as because of UDP retransmissions,  
> which "kills" the proxy if it becomes slow.
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Benny Prijono | 1 Aug 2006 11:38

Re: TLs performance

Hi all,

just to share my data, fwiw. In my benchmark, TCP (with single 
connection) performs almost consistently better than UDP in 
transactions and calls processing, but only when UAC and UAS are in 
local machine. When UAC and UAS are separated into different boxes, 
TCP performance is only about half of UDP performance.

For me, my data makes perfect sense, because in local machine, TCP 
transactions has lower cost to setup (e.g. less timers), so it should 
be faster. While on the network, the TCP round-trip probably prevents 
transaction to complete as fast as the UDP version, so TCP should be 
slower. So I'm a bit surprised that in your benchmarks TCP 
outperformed UDP, but perhaps it's just some tuning in the socket 
settings (any info on these will be appreciated).

Btw my benchmark report can be found here:
http://www.pjsip.org/testing/0.5.6.5/bench.htm

-benny

Cullen Jennings wrote:
> 
> Klaus, first of all thank you for producing some real results we can 
> discuss.  Just to validate some of your results - this is not the first 
> time I have seen performance results where TLS (or more specifically 
> TCP) has better performance that UDP. I have seen this on other products 
> too and when I think about it, it is not that surprising.
> 
> Cullen
(Continue reading)

Permalink | Reply | 4 comments |
headers
Thomas.Froment | 1 Aug 2006 11:57
Picon

Re: TLs performance

"I think TLS performs better as because of UDP retransmissions, which 
"kills" the proxy if it becomes slow. "

That's why I think it is not possible to make performance testing  in 
UDP without activating some kind of flow regulation mechanism... 
overwise the results are very difficult to interpret: what does it mean 
to test a proxy overloaded by retransmissions?.... Should always test 
performances on a stable rate, overwise this is a resistance/torture test...

Cullen Jennings wrote:
>
> Klaus, first of all thank you for producing some real results we can 
> discuss.  Just to validate some of your results - this is not the 
> first time I have seen performance results where TLS (or more 
> specifically TCP) has better performance that UDP. I have seen this on 
> other products too and when I think about it, it is not that surprising.
>
> Cullen
>
>
> On Jul 24, 2006, at 10:59 AM, Klaus Darilion wrote:
>
>> Hi!
>>
>> I made some tests with sipp+openser:
>>
>> scenario:
>>
>> UAC <-TLS-≥ openser <-TLS-≥ UAS (all of them got its own 2xP3 1,26GHz 
>> machine, linked with 100MBit). Simple forwarding configuration (like
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Rosen | 1 Aug 2006 14:33

RE: Voice codecs

I read this a couple of times before I grokked it.  I think you are right in
the big picture, but maybe not in the practical world we live in now.

Ideally, you would like to "search" the available transcoder inventory among
the originating, terminating, and possibly
services-within-the-peering-fabric domains to see if you can find an
available resource that bridge directly between the endpoint's actual
capabilities.  We don't have any protocol mechanisms which would do that.
That involves a distributed discovery mechanism with two lists -- find me an
available transcoder that can bridge between any codec on list A and any
codec on list B, and while we're at it, optimize two such discoveries
simultaneously.  Ideally, you would like both sides of one call to go
through the same resource, and not two different ones.

Do we need to get to this new protocol before we have something functional
in SPEERMINT?  I think not.  Many interdomain wireless call today would
transcode twice (from one wireless codec to G.711, across the PSTN to
another carrier and transcode from G.711 to its codec).  We often do this
even if they are the same codec on both carriers.  I suspect we do the same
thing for now, and work towards a better way.  I think the better way is not
a SPEERMINT charter item, but perhaps we could write a requirements doc for
someone else.

It's an interesting problem.

Brian

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@...]
> Sent: Tuesday, August 01, 2006 8:13 AM
(Continue reading)

Permalink | Reply | 569 comments |
headers
Richard Shockey | 1 Aug 2006 16:24
Picon

RE: TLS for peering (wasRE:Comments (RE:requirementsdraftsubmitted))


> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@...]
> Sent: Tuesday, August 01, 2006 3:04 AM
> To: Lee, Yiu
> Cc: speermint@...
> Subject: Re: TLS for peering (wasRE:Comments
> (RE:[speermint]requirementsdraftsubmitted))
> 
> 
> End to end certificates seem like they would be used with the S/MIME
> portion of SIP. I don't think anyone has been suggesting one should
> mandate that. I don't think we should confuse the TLS stuff with end
> to end security.
> 
> With the TLS stuff you only compare the name in the certificate to
> the next hop that you are routing too. I think this is fairly well
> defined and lots of people have implemented that part of 3261. (I
> agree there are problems with implementing sips but again, I don't
> think anyone is talking about using sips here).
> 
> I will note that many enterprises today peer IM with folks like MSN/
> Yahoo/AOL using SIP and it is mostly done over TLS.

Yes but that is edge to edge, not end to end.

I'm convinced that we are going to make very little progress unless we state
that the first iteration here of speerming is really edge to edge oriented.

I agree that anything that looks like end to end is rat hole #32
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Shockey | 1 Aug 2006 16:42
Picon

RE: Voice codecs


Interesting problem but easily solvable. 

The issue as I see it is we have to separate anything that looks like policy
and capabilities discovery from the basic issue if connectivity.

Now one issue we have is how do you discover the acceptable codecs for a
particular federation.

OK that is a simple database issue. Presumably based on the domain part of
the SIP URI how do you issue a query? 

I'm starting to think IRIS begins to look good here as the mechanism for
discovery of policy related information re a TN or a domain.

When we did some work in the US ENUM forum we decided to specify that the US
ENUM implementation in e164.arpa would use a IRIS database for what would
essentially be Line Level and or Whois like data associated with a E.164
number.

We knew this would eventually be essential. Say you cannot connect to a
particular URI' what is the contact data associated with that URI you need
to report a problem etc.

It would seem perfectly reasonable to construct various XML schemas various
capabilities of federations and then query those. You have to have a
response mechanism that is structured and right now IRIS is the best
candidate we have for structured database queries.

http://www.ietf.org/html.charters/crisp-charter.html
(Continue reading)

Permalink | Reply | 570 comments |
headers
Brian Rosen | 1 Aug 2006 17:17

RE: Voice codecs

Nope, it's more interesting than that.  Sure, each domain has a policy of
what codecs it allows on its network, but if you want to avoid double
transcoding, you want to know, really, what is happening on both sides of
the peering, to see if you can optimize it.

Suppose A allows g.711 and AMR, and B allows g.711 and EvRC.  You know what
is really going to happen.  The AMR handsets get transcoded to g.711 on A,
the EvRC handsets get transcoded to g.711 on B and they "work".

But what you really want to know is whether there is a transcoder available
on either side (or in the middle) for EvRC to AMR and vice versa.

If that example doesn't convince you, suppose A's list was g.711 and AMR-WB
and B's list was g.711 and VMR-WB.

So, you don't want to force A or B to transcode to the federation's list if
you can figure out what the "right" thing to do is.

You want to take the list of codecs the originating endpoint really can do,
and the similar list from the terminating endpoint, and see if you can
discover a resource that can bridge across the lists.

This isn't a policy issue really.

Brian

> -----Original Message-----
> From: Richard Shockey [mailto:richard@...]
> Sent: Tuesday, August 01, 2006 10:42 AM
> To: 'Brian Rosen'; 'Drage, Keith (Keith)'; speermint@...
(Continue reading)

Permalink | Reply | 570 comments |

Gmane