Slashdot Mirror

← Back to Stories (view on slashdot.org)

SIP: Creating Next-Generation Telecom Applications

Posted by michael on from the fun-with-java dept.

An anonymous reader writes "In this article, you'll discover how the Session Initiation Protocol (SIP) operates and, building on that knowledge, you will learn how to use the Java SIP Servlet API to build new applications that can run on telecommunications networks. The SIP tour concludes with code examples that demonstrate SIP application development in action."

18 comments

  1. Welcome ! by Anonymous Coward · · Score: 0

    I, for one, welcome our new Next Generation overlords. Next time the crew of the Enterprise calls, give them a warm hello!

    1. Re:Welcome ! by Anonymous Coward · · Score: 0

      When they first scan the Earth's internet for signs of intelligent life, they will receive a Skype call with the message:
      "Live Well and Prosper."

  2. When all you have is a hammer.... by Anonymous Coward · · Score: 2, Insightful

    Excellent! A derivative of a non-real time, bulk data transfer protocol family (SMTP, HTTP) being used for real time signalling applications.

    While the HTTP request/response model has served the IETF well enough for many things, perhaps they should consider more protocol models than the single hammer they seem to have equipped their toolbox with.

    1. Re:When all you have is a hammer.... by isj · · Score: 2, Interesting

      First, IETF does not really control the standards. The standard committees and the working groups do. If a working group prefers HTTP request/response then so be it.

      Second, SIP was developed when HTTP request/response seemed like the new way of doing a lot of stuff. It has disadvantages (verbose, textual, lot of cruft you don't need) and advantages (already specified, clear way of extending it, MIME support)

      Third, SIP and other protocols used/specified by the telecom industry tend to have layer upon layer. If 1 layer is good, then 10 layers must be ten times as good. Have fun looking at OSP (Open Settlement Protocol)

    2. Re:When all you have is a hammer.... by jgrahn · · Score: 1

      SIP and other protocols used/specified by the telecom industry tend to have layer upon layer. If 1 layer is good, then 10 layers must be ten times as good.

      Huh? Last time I checked, the major alternatives were SIP and H.323. H.323, not SIP, is the overspecified, layered monster from the telecom industry. (Although I'm sure SIP sucks, too.)

  3. Yes... by 4of12 · · Score: 3, Interesting

    Another great contribution to providing free public documentation by IBM. Kudoes to them.

    Meanwhile, there's that oncoming train about states requiring VoIP providers to become fully bureaucratically functional telephone providers....

    A good dose of well-meaning out-dated regulation ought to slow down the adoption rate of good new technology.

    --
    "Provided by the management for your protection."
  4. How SIP operates...? by Anonymous Coward · · Score: 1, Insightful

    I am not sure if that article really explains how SIP operates as much as the Java API the article refers to operates.

    For instance, it does not get into SIP message forking, spiralling, and time outs, nor does it explain how the ACK (the only request which does not get a response) is sometimes considered part of the INVITE transaction, and sometimes it is not, nor how authentication works, or message encryption.

    No mention of the use and differences between CANCEL and BYE.

    There appears to be only a brief mention of the REGISTER message, or the concept of location servers, which is a key point allowing users to find one another.

    The typical anti-B2BUA swipe is not surprising, but really should have more substantiation.

    No mention of media negotiation -- while the session media is separate from SIP, the negotiation process is not. (Particularly when reliable-100 + 183 provisional media are involved, or in the 3GPP case when a transcoder may be needed.)

    No mention of STUN or other NAT issues, or the use of TCP vs. UDP.

    At best this is a taste, a mere sip of SIP, not close to how SIP attempts to operate, with the completely misleading statement of "This article, however, should make clear that SIP is a relatively simple protocol." -- which is utter nonsense. Relatively simple to WHAT? At one point, and it may still be, the core SIP RFC was the largest single RFC ever published, not counting the supplementary drafts and extentions -- this should give one a feeling for the 'simplicity'. Handling a case with forking, spiralling, authentication, negotiation, and NAT between endpoints with differing capabilities connecting through a group of record-routing proxies with the session-timer running is NOT simple.

    It is the article which is relatively simple, not the protocol.

  5. how does SIP compare to Jabber? by BigGerman · · Score: 1
    Jabber protocol seems conceptually very close (user agent talking to server, server talking to server, server taling to other UA) but Jabber IMHO is somewhat better organized (more XMLish).

    Anyone has opinions on that?

    1. Re:how does SIP compare to Jabber? by Anonymous Coward · · Score: 1, Interesting

      Total agreement. Jabber at least has a consistant, simpler set of syntax and parsing rules, and is more willing to bend on the 'dumb core, smart edge' obsession that besets SIP to the point of idiocy.

    2. Re:how does SIP compare to Jabber? by Anonymous Coward · · Score: 1, Informative

      Here's some more info about SIP.

    3. Re:how does SIP compare to Jabber? by Anonymous Coward · · Score: 1, Informative

      Isn't Jabber using the H.323 protocol for session initiation? Jabber as a whole is much biger protocol than SIP so there's no point to compare them.
      It's common misunderstanding. SIP is only for session initiation. For content exchange You have SDP protocol for example, which very often comes together with SIP.

    4. Re:how does SIP compare to Jabber? by Anonymous Coward · · Score: 0

      SIP is only for session initiation. Except for REGISTER method which is used to provide presence services. And the MESSAGE method, which provides Instant Messaging content inside SIP messages. And re-INVITEs which allow for session modification, not just initiation. And REFER and INVITE forking, which provide call application/services (follow me, multiple ring, call transfer) not just session intiation. And you have 183/PRACK and COMET for media negotiation during the initiation. And don't forget about the use of CGI and servelet interfaces for remote application invocation. And SUBSCRIBE and NOTIFY for event notification and the potention for remote UI management.

      It's a common misunderstanding that SIP is only for session initialization. It's a floor wax and a dessert topping!

      SIP as a whole is a much bigger protocol than jabber -- if you take in all the SIP extensions, 3GPP needs, SS7 interop/bridging needs, 100-reliable, session timer, NOTIFY/SUBSCRIBE, MESSAGE, SIMPLE, REFER... conference call floor control, INFO, DTMF transmission...

  6. Huh? by jhannes · · Score: 1
    Did you even read enough of the article to see what SIP does? SIP uses RTP for the media trafic ("real time applications"). Using a "bulk data transfer" for call signaling seems quite appropriate to me. How quickly do you really need your phone to start ringing?

    Also notice that SOAP uses HTTP for RPC. HTTP is hardly bulk anymore.

    1. Re:Huh? by Anonymous Coward · · Score: 0

      I need the phone to start ringing about as fast as I need someone to answer a 911 call.

    2. Re:Huh? by pyrrhonist · · Score: 1
      How quickly do you really need your phone to start ringing?

      SIP devices start ringing before their bearer (RTP) is connected (i.e. 180 Ringing is before RTP stream gets set up). In contrast, a black phone (regular telephone) won't start ringing (alerting) until the bearer is connected. This has usability issues, because people are used to the way that regular telephones operate. If the bearer fails on a SIP phone, the phone call can still connect (i.e. the signalling worked), which can confuse both users. In a regular phone system, this doesn't happen. The called party's phone won't ring, and the caller will get the reorder tone.

      --
      Show me on the doll where his noodly appendage touched you.
    3. Re:Huh? by Anonymous Coward · · Score: 0

      Actually, in some of the 3GP call scenarios I've seen, there is a whole set of media negotiation message done inside the INVITE transaction (183/PRACK/COMET/KITCHEN_SINK/etc.) done to set up and reserve the celluar channel and bandwidth for the connection before the cell phone will ring. It does take care of the above usability problem, but at the cost of a lot more message exchanges and complexity.

      It's possible that by now some of that mess was cleaned up, but I suspect whatever remains is still ugly. (The interactions with this sort of thing and delayed media INVITE scenarios and third party call control (3PCC) can get downright nasty.) I cheerfully look forward to seeing a SIP INVITE with delayed media fork to two separate 3GP cell phones.

      The basic problem is the HTTP request/response model that SIP is based on -- the assumption that you can complete the entire transaction with a single request, and a single response. When early media, media negotiation, message retransmissions, and all start showing up because of the Real World, the model started being stretched in very awkward ways because you could no longer stick to the basic request/response model. (Reliable 100 with its own set of message sequence numbers inside of the the normal SIP Cseq: message number comes to mind. ACK requests that have no responses, etc.)

    4. Re:Huh? by Anonymous Coward · · Score: 0

      Oh yes... don't forget in a non-reliable 100 call scenario over UDP, that the 180 Ringing might never make it back to the caller. That is, the call might place the call and hear nothing but silence -- until the other end suddenly picks up. Not quite as bad a usability issue.

  7. INFORMATIVE? It's DISinformative! by axxackall · · Score: 1
    Isn't Jabber using the H.323 protocol for session initiation?

    Where did you get this crazy misunderstanding? Jabber uses XMMP, which is lightweight protocol. Well, jabber uses H.323 - but only for voice over IP extensions/applications, not for regular sessionmanagement.

    Who is the idiot that modded up the parent as "informative"? Check the "information" before you rate it!

    --

    Less is more !