Subject: [SIP] What do we want with SIP?

From: "Arnoud van Wijk (ETM)" <[email-masked]>
Date: Thu, 3 Aug 2000 11:38:43 +0200

Scott Petrack's message indeed made me realise that to my impression we all are not really sure on what the duty for SIP will be.
A real danger what is possibly going to happen is that we all want to add headers and other extensions to SIP, that before we realise, SIP will act like a fat pregnant elephant instead of a sleek and fast gazelle.

SIP is indeed very good at Initiating a Session, and then hand it off to a different protocol. Like RTP or RSVP etc. Preconditions set in the header will also be a good idea, but for exactly which protocols?

In fact, what do we plan to use SIP for? We all have a different idea what we want SIP to do for ourselves. I am not immune either.
Maybe it is a very good idea to form a consensus on what we want SIP to do for us.
Do we want SIP for:
Only IP-telephony?
Also Multimedia IP sessions on 1. a computer, 2 a mobile digital board (PIM/PDA/WAP/UMTS phone etc)?
Do we want home appliances and other machines be able to send us info via SIP?
Do we want to send instant messaging via SIP?
Do we want SIP to track mobility of the user?
Do we want to use SIP to handle the AAA services? (Billing of network usage and QoS and the service from content providers, like a database search or keeping track of the IP session duration and the amount of data passing through the UAs used for the session)?

With good planning, many of those tasks can overlap each other.

If we try to make a list of what the required duties of SIP are and what can be handed off to the protocol that SIP is initiating the session for.
Then we can really define which headers are really necessary for SIP (like the media type <video, audio, text> and language <english, dutch, french>, and which headers will just refer to the preconditions of the handed off protocol <Security options and QoS options and OSP tokens for AAA services>).
With our combined visions, we should be able to do this. 
The ideal to obtain is publish it once and then many years without any new versions of SIP. While the possebilities of SIP continue to expand (at application level).

Also, when we know which protocols are required to team up with SIP, we will get those protocols also finished and ready for use.
Future protocols should be easily be added to SIP in the Content-Type header (draft-ietf-sip-rfc2543bis-00).
So that most future changes will be on UAs level on how to process the offered protocols, instead of how to send/receive and read/write/understand SIP messages.

Well those were my 2 Euro cents.
This mail is not intended to show any disrespect nor to discard all the efforts. I just hope to have all of us team up and sail in ONE direction.

Arnoud
_______________________________________________________________
ERICSSON TELECOMMUNICATIE BV
Arnoud van Wijk
Research & Development
ETM/BL/RE
Fax: +31-161 247569
_______________________________________________________________

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

---

From: "Srinath A" <[email-masked]>
Date: Thu, 3 Aug 2000 16:21:48 +0530

Hi all,
    In my opinion, the fact that SIP is being extended to incorporate functions other than Session
Initiation, need not be one that has a negative impact. The reason for this is that all these
extensions add features to the protocol that are relevant to a particular service, like say IM, in a
manner which does not affect the operation of other functions. Many of these extensions probably
make use of the User location and authentication facilities offered by SIP in order to achieve their
goals. All the specific processing takes place in the end points, which are configured to particular
needs. If an end point does not support the MESSAGE  method then it rejects it. Another UA will
probably take care of IM only.

    The network components should take care of routing in an extension independent fashion.All
extensions should place least requirements on these elements. These rules should ensure
interoperability among devices with varying capabilities.

    A suggestion:  Is there harm in trying to incorporate MGCP functionality into SIP using the
presence and IM extensions, similar to the control of  NA's ? :-)

    Comments?

Regards,

Srinath A
 Silicon Automation Systems       Phone: 5276100, 5276108 extn 4220
 #1309, 10th Main, HAL III Stage
 Bangalore 560 008, India
Company Home: www.sasi.com
Home: http://www.geocities.com/srinath_tvpm

----- Original Message -----
From: Arnoud van Wijk (ETM) <[email-masked]>
To: 'SIP' <[email-masked]>
Sent: Thursday, August 03, 2000 3:08 PM
Subject: [SIP] What do we want with SIP?

> A real danger what is possibly going to happen is that we all want to add headers and other
extensions to SIP, that before we realise, SIP will act like a fat pregnant elephant instead of a
sleek and fast gazelle.
>
> SIP is indeed very good at Initiating a Session, and then hand it off to a different protocol.
Like RTP or RSVP etc. Preconditions set in the header will also be a good idea, but for exactly
which protocols?
> Do we want to use SIP to handle the AAA services? (Billing of network usage and QoS and the
service from content providers, like a database search or keeping track of the IP session duration
and the amount of data passing through the UAs used for the session)?
> If we try to make a list of what the required duties of SIP are and what can be handed off to the
protocol that SIP is initiating the session for.
> Then we can really define which headers are really necessary for SIP (like the media type <video,
audio, text> and language <english, dutch, french>, and which headers will just refer to the
preconditions of the handed off protocol <Security options and QoS options and OSP tokens for AAA
services>).
> The ideal to obtain is publish it once and then many years without any new versions of SIP. While
the possebilities of SIP continue to expand (at application level).
> So that most future changes will be on UAs level on how to process the offered protocols, instead
of how to send/receive and read/write/understand SIP messages.
> This mail is not intended to show any disrespect nor to discard all the efforts. I just hope to
have all of us team up and sail in ONE direction.

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 03 Aug 2000 06:53:53 -0500

When the phone was invented its main purpose was believed to be
to enjoy opera music from home. Interactive conversations were
not on the list of applications. Have a nice set of prints from
the 1890's about the "Future of the Telephone" on this topic.

Henry

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Srinath A
>Sent: Thursday, August 03, 2000 5:52 AM
>To: siplist
>Subject: Re: [SIP] What do we want with SIP?
>
>
>Hi all,
>    In my opinion, the fact that SIP is being extended
>to incorporate functions other than Session
>Initiation, need not be one that has a negative
>impact. The reason for this is that all these
>extensions add features to the protocol that are
>relevant to a particular service, like say IM, in a
>manner which does not affect the operation of other
>functions. Many of these extensions probably
>make use of the User location and authentication
>facilities offered by SIP in order to achieve their
>goals. All the specific processing takes place in the
>end points, which are configured to particular
>needs. If an end point does not support the MESSAGE
>method then it rejects it. Another UA will
>    A suggestion:  Is there harm in trying to
>incorporate MGCP functionality into SIP using the
>> Scott Petrack's message indeed made me realise that
>to my impression we all are not really sure on
>what the duty for SIP will be.
>> A real danger what is possibly going to happen is
>that we all want to add headers and other
>extensions to SIP, that before we realise, SIP will
>act like a fat pregnant elephant instead of a
>sleek and fast gazelle.
>>
>> SIP is indeed very good at Initiating a Session, and
>then hand it off to a different protocol.
>Like RTP or RSVP etc. Preconditions set in the header
>will also be a good idea, but for exactly
>which protocols?
>>
>> In fact, what do we plan to use SIP for? We all have
>a different idea what we want SIP to do for
>ourselves. I am not immune either.
>> Also Multimedia IP sessions on 1. a computer, 2 a
>mobile digital board (PIM/PDA/WAP/UMTS phone
>etc)?
>> Do we want to use SIP to handle the AAA services?
>(Billing of network usage and QoS and the
>service from content providers, like a database search
>or keeping track of the IP session duration
>> If we try to make a list of what the required duties
>of SIP are and what can be handed off to the
>> Then we can really define which headers are really
>necessary for SIP (like the media type <video,
>preconditions of the handed off protocol <Security
>options and QoS options and OSP tokens for AAA
>services>).
>> The ideal to obtain is publish it once and then many
>years without any new versions of SIP. While
>> Also, when we know which protocols are required to
>team up with SIP, we will get those protocols
>also finished and ready for use.
>> Future protocols should be easily be added to SIP in
>the Content-Type header
>(draft-ietf-sip-rfc2543bis-00).
>> So that most future changes will be on UAs level on
>how to process the offered protocols, instead
>> This mail is not intended to show any disrespect nor
>to discard all the efforts. I just hope to

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Aug 2000 10:14:39 -0400

> presence and IM extensions, similar to the control of  NA's ? :-)

Three reasons not to do this:

- two protocols already exist for this (MGCP and Megaco);

- very few of the SIP mechanisms are useful here. Generally, MGs and
MGCs are stationary (with regards to each other), for example.

- SIP is peer-to-peer, MGCP/Megaco is master-slave.

This is indeed one good example where the model does not fit well. SIP
is not a reliable datagram protocol for random content.