Slashdot Mirror

Hahahahaha !

SIP a single RFC? Can you imagine the number of SIP related RFCs and associated drafts? SIP WAS simple, it is now a mess. Even if we restrict to RFC 3261, if you can asnwer the following questions you are already a MASTER in SIP:

- what is the difference between request URI and the "To" header? Are they redundant?
- what is the difference between the "Contact" header, the "P-Asserted-Identity" header and the "From" header?
- what is the loose routign mechanism and what is the relationship with the "Via" headers?
- what is the need for "from tags" and 'to tags".

If we go a bit further:

- Why is SIP/SIMPLE do we need to introduce an "etag" and why not resuing the callid ?
- etc.

We are a company that is based on SIP and very in favor of this protocol mostly form market reasons but one should not be blind: this protocol has its problems like any other. At the beginning, it was sooo "simple" that it could not even support "announced transfer" or line supervision which is a must for corporate telephony then the real people jumped in and added what it takes to make it usable and added complexity.

Even the big telco that are hated so much in this forum jumped in and created the IMS standards based on SIP (under the ETSI Umbrella = European ...). They took it to the next level of complexity but they NEEDED IT because they are the guys who enable you and me to call from A to B without even thinking about how this is done (since more that 100 years).

If you imagine one second that you can only read ONE RFC to start working on the real SIP world, you are VERY WRONG (see RFC 3581, RFC2327, RFC 3264, RFC 3550 + all the RFC dedicated to packetization, SIP/SIMPLE, MESSAGING, ....)

Now if you compare SIP with H.323, I agree that initially, one can see a lot of advantages.
- H323 has a stupid protocol layering
- slow dialog establishment, etc?
and although they have improved this, this is still not perfect but they have advandages as well:

- camera control and double video streams are a reality in H.323 world wher in SIP it is still on paper only and badly documented.
- screen and application sharing are a reality on H.323 world. They are non existant in SIP
- H.323 has defined a clean standard for NAT traversal where SIP has a set of "best practices" spread in various RFC (keepalive, rport, symetric RTP, etc.).

if you cannot read the ITU standards that is basically because:
- most of them need to be bought
- they have a strong culture of separating the function and the encoding, which renders them difficult to grasp for field hackers
- ITU protocols are often based on ASN.1 BER encoding and therefore are compact an binaries and cannot be test with a simple TELNET connection, which seems to trouble a lot of Internet gurus.

Emmanuel
http://www.ives.fr/

I disagree with the previous posts. In that case, technology matters.

A good city wide network should

- handle proper user density
- have a good coverage
- handle multi-media application such as audio / video over IP
- terminal should have a good battery life and reasonable costs

Please note that

- Wifi is certainly not designed to handle user density unless the number of access point is high. Until 802.11n, all users share the same radio channel in a pseudo random way. No frequency allocation,
- the above characteristics makes current wifi standard unfit for true bidirectionnal application such as video over IP as we do not have a true two way simultaneous communications. Even with 802.n, the number of available frequency is so few that only a few people would really be able to beneficiate the proper quality. This does not match the need of high density areas.
- it is a known fact that Wifi has not been designed with battery life in mind. A lot of wifi equipped terminal makers are struggling with this issue.

When comparing the other potential tehcnologies : 802.20e (Wimax) and 4G / LTE, there is no much choice

- 4G / LTE has the expected characteristics but is so complex that it is out of reach of medium sized organisation.
- only Wimax stand a chance.

Then you have to deal with safty regulation on radio protection.

Yes, technology does matter in that case.

http://www.ives.fr/

Hello

I still wonder why so many people moan about H.264 licensing fees. It is quite reasonable and is not stupidly overpriced as in the case of AMR audio codec. Here are the terms of MPEG 4 LA

In the case of the (a) encoder and decoder manufacturer sublicenses: For (a) (1) branded encoder and decoder products sold both to end users and on an OEM basis for incorporation into personal computers but not part of an operating system (a decoder, encoder, or product consisting of one decoder and one encoder = âoeunitâ), royalties (beginning January 1, 2005) per legal entity are 0 - 100,000 units per year = no royalty (this threshold is available to one legal entity in an affiliated group); US $0.20 per unit after first 100,000 units each year; above 5 million units per year, royalty = US $0.10 per unit. The maximum annual royalty (âoecapâ) for an enterprise (commonly controlled legal entities) is $3.5 million per year 2005-2006, $4.25 million per year 2007-08, $5 million per year 2009-10.8

This means that if you would start a company that would sell a product that would embbed ffmpeg / x264 (you have to release the sources in that case because of GPL ...), you would not have to pay anything for your first 100 000 units, the above 100 000, you have to pay $20 000 / year so 0.20 $US / year / user. This sounds reasonable.

Of course such approach is not compatible with the GPL philosophy that emphasises the "no string attached" philosophy but H.264 development did not come free either. I wonder if the devlopper of x264 could not sell non GPL licences of their codec with a low price: 2$ per unit + 0.5$ per year per unit for support and patent fees. This would enable anyone wanting to do business to have a sound legal base and channel more money in open source codec developments.

Emmanuel. IVeS

Depends how network neutrality is defined.

If network neutrality means that every single IP packet ought to be processed equally then it is a big hindrance to innovation because basically, we will never see the emergence of differenciated QoS on the net. The later is deseperatly needed to support interactive video services such as the ones we are developping. This is basically Kahn's point.

Internet has been designed to be a dumb but very robust network (rememeber the Rise of the Stupid Network) as opposed to telephone network, more complicated and offering services at the network level rather than on terminals themselves. Kahn's view (and I share it) is that Internet may need to provide smarter services such as several class of transport and a real bandwidth management.

For instance the current media transport standard which is Real Time Protocol is the best we can get but comparted to an ATM virtual circuit, it is pretty depressing.

Some people would like to make a compromise and define network Neutrality as uniform handling of services across ISPs. But then this would require to define:

• How are e-mail services handled
• How are web services handled
• How are real time services handled

This way too much regulation for ISPs and anglosaxons :).

As a matter of fact, on highway, you have cars, trucks and in some of our European highways, some of the lines are dedicated to slow vehicules.

Regarding the concept of net netrality, I am not at ease with it:

• If this is about business fairness that ISP shoud not silently the content that they are hosting, I would agree
• If this is about content provider not wanting to share the pie with ISP for the infrastructure, it will either have a negative effect on the future of Internet as ISP might not be able to finance the infrastructure needed to support new demanding interactive services or end up with vertical integration for some big service providers in order to finally implement class of service on the Internet
• If this is about this Internet dogma that consists in saying that every IP packets are equal, I vote fully against this.

Having founded a company to offer interactive video service, I would love to be able to request a specific class of service for the video for IP communications that we use.

A class of service where my RTP packet would be garanteed to be delivered in order with a fixed latency,predefined frequency, dropped in case of congestion with bandwidth reservation. And this, end to end regardless of the ISP hosting my servers and regardless of the ISP used by my customers.

Of course, I would pay this and charge it back to my customers as part of my service fees.

This is currently not possible and will never be if the dogma on absolute equality of all IP packets is turned into law. I am coming from the telco world (yes, SS7, circuits and all the stuff) and I believe that some of the telco technical heritage has to make its way into the Internet for its own sake.

The only aternative would be to setup an IP VPN between me and my customer. I suspect that some other innovative service providers are thinking along the same lines. In effect, those VPN might eventually coalesce and we might see new IP network appear dedicated to media transport, parallel to Internet because of this stupid domga.

Emmanuel
IVèS