Subject: Why SIP? (Was Re: [SPIRITS] Some Thoughts On Protocol Requirements)

From: Igor Faynberg <[email-masked]>
Date: Tue, 03 Apr 2001 19:19:37 -0400

Ladies and Gentlemen:

I have just returned after being away from e-mail for two weeks, and
found this thread, to which--granted--I have given a much higher
priority than the rest of 2,768 messages, which are still waiting.

First, in response to Bruce Chapman, whose message started this
exchange, I say that I would be happy consider any request to update the
requirements got quite a few comments and plan to start this job
sometime next week.

I was surprised that no one presented a SIMPLE answer to Bruce's query
regarding the current choice of SIP for SPIRITS: RFC 2995 has listed a
number of pre-SPIRITS implementations for Internet Call Waiting (and
other services), which have ALL been implemented using SIP! 
(Conversely, no non-SIP implementation has been reported or even
discussed.)

With PINT, the situation was totally different: RFC 2458 has listed
several implementations, of which NONE used SIP. Still, based on the
review of the problems with these implementations, SIP was presented in
RFC 2458 and recommended for a number of reasons, all of which,
incidentally, hold for SPIRITS.

I have been watching the discussion of using HTTP, but I feel uneasy
about even discussing it because there have been no prototyping known to
us, except, of course, for Lawrence Conroy's Call Center report, which
is now part of RFC 2458, and which explicitly lists the shortcomings of
using HTTP. I disagree with the argument that SIP INVITE and
SUBSCRIBE/NOTIFY are incidental--they are precisely what SPIRITS needs. 

Of course, a new protocol could be relatively easily designed, or HTTP
could be twisted and turned to do the job, but... why bother!?

SIP has been invented from the beginning to do for IP telephony what
Q.931/ISUP/INAP have been doing for the PSTN. We have already
successfully demonstrated that SIP can perfectly interwork with the PSTN
in support of services. (Incidentally, this is a thing on which both the
IETF and ITU-T agree, not to mention the wide industry support--cf.
proceedings of VON conferences, IEEE IN workshops in the past two years,
IEEE ICIN 2000, and many others.)

I am not quite sure what is meant by "vagrant servers," and why what was
good for PINT may not be good for SPIRITS. I would really like to see
some specifics before I understand.

On other points of the discussion:

1) Binary- vs. text-encoded protocols. I have been on the record for
years stating my preference for binary-encoded protocols for a variety
of reasons (absence of CPU-hogging parsing and clear definition of
semantics among the first two of them); however, I do believe in RUNNING
CODE. SIP is there, and the issue is moot. SIP has proved it can do the
job, and we have no time for academic exercises.

2) ASN.1 (I am just answering the point, although this list item is
clearly redundant in light of the previous one). In general, ASN.1 works
very efficiently if PER (not BER) encoding scheme is used. Using PER,
however, is problematic--to say the least--in the Internet environment,
because any change in the specification would require an update to all
hosts. 

3) XML. In addition to what Kumar has allured said quite eloquently, I
add that we discussed that issue at length in an ad-hoc corridor
conversations at the last two IETF meetings. Henning confirmed that SIP
can carry XMLed parameters right now, so I believe we should research
this option further and try to implement it ASAP.

4) INAP parameters. SPIRITS is not merely the means of transport of INAP
parameters--it does much more than that. A list of INAP parameters to be
chosen will depend on specific proposals and the discussion (please see
the "methodology" section of the requirements). I think Frans Haerens
has made an excellent point when he suggested that we take a look at
Parlay specifications as a starting point. People who have designed an
API clearly had many services in mind, and we ought to build on their
experience. (Incidentally, the SPIRITS protocol's support the Parlay API
would be an excellent by-product of the effort, especially important to
wireless services--to which Jorge alerted us--as 3GPP accepted PARLAY
API.)

I love to have an odd number of items in a list, but I cannot think of
the fifth item. (Whoever throws the first stone at me, may suggest it.)

Having said all that, I am making a proposal: let us consider using any
other than SIP protocol in SPIRITS only after someone has implemented
it, at least for the base SPIRITS services.

If we go into the business of discussing new protocols solely on
theoretical basis, this group will never meet its milestones...

Respectfully,

Igor

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: 황진경 <[email-masked]>
Date: Wed, 04 Apr 2001 20:02:22 +0900

I have read the draft you sent to SPIRITS mailing group.(SOAP)

It's very interesting to me for now, because I am concerning about service
architecture in NGN like packet network, especially for telephony services.
The issue would be focused to the service triggering framework(mechanism)
between application control and call control.

In my first insight, your reference can be one of the candidates for it.

I hope to confirm then,
Do you think 'the SIP extension'(SERVICE mechanism) can provide the triggering
architecture for value-added telephony service (such as call forwarding on
no-answer, free-phone, time-dependent routing, etc) in the SIP-based (NGN)
networks ?

Any response or forwarding or reference would be very appreciated.

Thank you-

Jinkyung Hwang
Korea Telecom

"Roy, Radhika R, ALCOO" wrote:

> Folks:
>
> It might be interesting to see the enclosed draft.
>
> Radhika R. Roy
>
> Technology Consultant
> AT&T
> Room 3D-2C09
> 200 S. Laurel Avenue
> Middletown, NJ 07748
> +1 732 420 1580
> [email-masked]
>   ------------------------------------------------------------------------
>                                    Name: draft-deason-sip-soap-00.txt
>    draft-deason-sip-soap-00.txt    Type: Plain Text (text/plain)
>                                Encoding: quoted-printable