Subject: SDR tool

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 25 May 1999 10:05:11 +0300

Hi,

I was trying to check if a SIP UAC/UAS that I've got could interoperate
with standard SIP tools. I chose the SDR tool for this test.

I've noticed that: first of all, an INVITE request is sent, with a
session description written using SDP... but then, the 200 OK response
does not contain any session information... and there is no ACK at all.

Since SDR is designed for the MBONE, multicast is used, and therefore, a
second session description is not needed.

Is this a standard SIP behaviour? (I thought that we always had to
return an ACK).

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 May 1999 10:53:39 -0700

SDR implements an early version of SIP and is not compatible with the
rest of the SIP world.

---

From: Sanjay Nayak <[email-masked]>
Date: Wed, 26 May 1999 08:49:38 -0700

I am  intretsed in the issues involved  in SIP and QOS, specially following
once.

1. Can any one of the method of  SIP can accomodate the QOS parameters (
bandwidth, latency ..).  So that we need not go for  any resource
reservation protocols. During the phase of the session establisment , we
can  make sure that  bandwidth is available end-to-end.

2. IT seems to be that SIP will compleatly isolate the control plane from
data plane. that means connection estblishment  path is different from the
data path. won't his be a problem for QOS issues. how to gauretee the
end-to-end QOS  , if the signalling path is different from the data.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 May 1999 13:16:08 -0400

> end-to-end QOS  , if the signalling path is different from the data.

As you mention, the control path (i.e., SIP), and the data path (RTP),
are completely independent. Its worth a note that this is true for all
of the existing IP telephony protocols. I believe this to be a feature,
not a bug. As such, SIP (and SIP servers) cannot really have a
generically useful role in QoS negotiation. 

To handle QoS, we have a suite of tools at our disposal (namely RSVP and
intserv, diffserv). An end system requiring some level of QoS support
simply makes use of these tools. The advantage of using these generic
mechanisms is that they are application independent. Lets not forget
that IP telephony is one of many applications which require QoS support.
By using an application-independent set of tools, like RSVP and
diffserv, providers can have one central infrastruture to meet the QoS
requirements of all their applications.

There are some subtle interplay issues with these QoS mechanisms and
SIP. Namely, there are many who have the strong requirement that the
called parties phone not ring unless resource reservation has occurred.
This can be supported without putting any QoS in SIP; but rather using
some SDP parameters, interpreted at end systems. Look for an I-D on this
subject, to be released in the next few days.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Sanjay Nayak <[email-masked]>
Date: Wed, 26 May 1999 14:47:14 -0700

Any sample code of SIP is available  for  experiments

-sanjay