Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task for ce in Adelaide)

From: "Sinnreich, Henry" <[email-masked]>
Date: Wed, 24 May 2000 23:47:49 +0000

Agree Dave,

Our model has the edge router doing the RSVP aggregation to DiffServ and
also knowing the sum of all QoS streams. It is up to the policy server and
bandwidth manager to authorize any new application requesting QoS, SIP in
this case. The authorization depends on:
- the clearinghouse AAA,
- the SLS with the backbone,
- available BW in the local domain.

Henry

>-----Original Message-----
>From: Dave Oran [mailto:[email-masked]]
>Sent: Wednesday, May 24, 2000 11:28 AM
>To: Dean Willis; Michael Thomas
>Cc: IETF SIP
>Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP Security task
>force in Adelaide)
>
>
>If you're using Intserv at the edge the router at the edge of 
>the Diffserv
>cloud will likely know this and reject the reservation. No need for the
>proxy to get involved.
>
>The car analogy is not a good one because in the case of 
>highways you're
>already stuck at the bottleneck when you find out you're 
>screwed, as opposed
>to RSVP when you are essentailly clearing all the dead wrecks 
>out of your
>way before driving up the highway, ala Mad Max.
>
>Positing that a SIP proxy has a better idea what the QoS state of the
>Diffserv core is than the edge router at the edge of that core is like
>saying the radio announcer knows more about the tornado than 
>the Twister
>crew chasing it.
>
>If there's a oracle which knows the state of the core it can 
>tell the edges
>as easily or MORE easily than it can tell an undefined sea of 
>application
>proxy boxes.
>
>Dave.
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of Dean Willis
>> Sent: Friday, May 19, 2000 6:35 PM
>> To: Michael Thomas
>> Cc: IETF SIP
>> Subject: RE: SIP DiffServe (was RE: [SIP] Minutes of SIP 
>Security task
>> force in Adelaide)
>>
>>
>>
>> Ah. The networkstatus-aware proxy is effectively advising the SIP
>> user of congestion in the DiffServ network. Kind of like those
>> radio announcers that say "Highway 18 is shut down again --
>> please use surface streets or just stay home".
>>
>> The real question is to define a mechanism that allows the health
>> of the network to be assessed in some sort of meaningful way so
>> that this knowledge may be made available to the UAC.
>>
>> --
>> Dean
>>
>>
>>
>> > -----Original Message-----
>> > From: Michael Thomas [mailto:[email-masked]]
>> > Sent: Thursday, May 18, 2000 4:32 PM
>> > To: Dean Willis
>> > Cc: IETF SIP; Michael Thomas
>> > Subject: SIP DiffServe (was RE: [SIP] Minutes of SIP 
>Security task force
>> > in Adelaide)
>> >
>> >
>> > Dean Willis writes:
>> >  > Consider it in an aggregation model, like a donut. The chewy
>> > outside parts of the donut are controlled by IntServ. Traffic
>> > leaps across the DiffServ donut-hole only if the heuristic
>> > process thinks (IE, is reasonably sure) that there is adequate
>> bandwidth.
>> >
>> >    OK, but I still don't see what that has to do
>> >    with proxies. That sounds like something an
>> >    edge router would do before it admits diffserv
>> >    traffic into the diffserv core. Proxies are even
>> >    more clueless because they never see the actual
>> >    traffic patterns.
>> >
>> > 		Mike
>> > Hfæj)bz	b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿(tm)¨¥(tm)©ÿ-+-SwèþÈ©
>
>
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip
>

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

---

From: Alberto Conte <[email-masked]>
Date: Thu, 25 May 2000 11:44:28 +0200

All,

I would like to allow a user to send an INVITE message carrying an incomplete session
description specifying the list of media types to be used in the session without
indicating the RTP ports and addresses for receiving them. 

That should be useful in case of third-party control, or gateway between two
signalling protocols.

I thought to something like this:

v=0
o=Alberto 2890844730 2890844730 IN IP4 100.101.102.103
s=Hello!
t=0 0
m=audio 0 RTP/AVP 3
a=rtpmap:3 GSM/8000
m=video 0 RTP/AVP 32
a=rtpmap:32 MPV/90000

i.e. putting the port number to zero. 

Is it possible? Can be detailed in the next RFC?

Thanks in advance fo the help,
Alberto

---

From: Neil Deason <[email-masked]>
Date: Thu, 25 May 2000 11:13:12 +0100

> Is it possible? Can be detailed in the next RFC?

It already is used to infer a very different meaning from a callee to a caller. Look at
Appendix B - Usage of SDP ...

"If the callee wants neither to send nor receive a stream offered by the caller, the
callee sets the port number of that stream to zero in its media stream."

Cheers,
Neil.
--
Ubiquity Software Corporation, UK           http://www.ubiquity.net

---

From: Lars Berggren <[email-masked]>
Date: Thu, 25 May 2000 13:01:37 +0200 (CEST)

> indicating the RTP ports and addresses for receiving them. 

If your intention is to only send streams, not to receive them, you can
list them as sendonly (a=sendonly). See section B.2 in rfc2543 and
rfc2327. /Lars

> Thanks in advance fo the help,

Lars Berggren       <mailto:[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

---

From: Alberto Conte <[email-masked]>
Date: Thu, 25 May 2000 14:02:24 +0200

> callee sets the port number of that stream to zero in its media stream."

Thank you Neil for your answer. 

I know the content of Appendix B and I agree with you. However, as you say, the
"port=0" meaning has been fixed only in the case of calle -> caller response or in a
caller -> callee ACK, NOT in the caller -> callee INVITE message. 

I still think that is acceptable to state that the port=0 in an INVITE message means:
"I invite you for a session according with these medias, but at the moment I don't
have the RTP port and address". 

RTP port and address will be sent in the ACK!

Note that in my case the caller is not asking for a send-only session, but only
delaying the port and address information.

Cheers,
Alberto

---

From: Alberto Conte <[email-masked]>
Date: Thu, 25 May 2000 14:32:05 +0200

Lars Berggren a écrit :
> In this case you can send an INVITE without SDP, the callee lists streams
> in the 200, and the ACK can contain the final SDP. This behaviour is
> referenced in the spec. /Lars
> 

Sorry Lars, I don't agree with you.

Sending an INVITE without SDP means that the caller will be forced to choose the
medias exchanged in the session on the base of the ones proposed by the callee! 

This is not exactly what I want. I would like the caller able to force the callee to
accept its choice (or a part) of the medias, delaying only the RTP port and address
information.

---

From: Neil Deason <[email-masked]>
Date: Thu, 25 May 2000 13:59:03 +0100

> Lars Berggren a écrit :

<snip>

> accept its choice (or a part) of the medias, delaying only the RTP port and address

But by specifying the medias in an INVITE you don't 'force' the callee to accept the caller's
choice. It is the opening offer in the two parties agreeing on media types. If you do not include
the session description in the INVITE, the other party should offer it's supported media streams
and codecs in its 1xx or 2xx response. Your UA then sends a completed session description in the
ACK.

Cheers,
Neil.

---

From: Lars Berggren <[email-masked]>
Date: Thu, 25 May 2000 14:10:04 +0200 (CEST)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 May 2000 11:16:55 -0400

Another way to do it is to send the initial INVITE with the desired
media streams on hold (IP address set to 0.0.0.0). When you have
specific IP address and port information, you can do a re-INVITE, and
take the user off hold by passing an updated IP address and port in each
m line. Note that the update would not occur in an ACK, but rather in a
re-INVITE.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Alberto Conte <[email-masked]>
Date: Thu, 25 May 2000 18:04:58 +0200

Putting in hold the calle is a solution, but that increases the number of messages to
be exchanged, requiring a re-INVITE transaction!

The power of SIP is to reduce the message exchanged in case of no error. And this is
actually a case of no-error. It should be better allowing the caller to propose its
media request delaying only the RTP port information in the ACK.

Alberto

---

From: Lars Berggren <[email-masked]>
Date: Fri, 26 May 2000 10:23:13 +0200 (CEST)

> media request delaying only the RTP port information in the ACK.

I would rather think the power of SIP is its generality, flexibility and
simplicity. A re-INVITE is a very general and powerful mechanism to
accomplish many different tasks, including yours, so why not keep it that
way instead of specifying special cases which tend to make the protocol
more complex.

/Lars

---

From: Alberto Conte <[email-masked]>
Date: Fri, 26 May 2000 15:15:03 +0200

Sorry, but I still disagree. 

I don't think that specifying what does it mean a port number = 0 in the INVITE
message (which is at the moment not defined in the RFC 2543) is a way to make the
protocol more complex. 

I think it is just a way to ensure implementation compatibility by specifying how
this kind of message must be handled. That will never prevent to use the solution
proposed by Jonathan.

Alberto

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 26 May 2000 10:28:48 -0400

> message (which is at the moment not defined in the RFC 2543) is a way to make the

Unfortunately, what you are proposing to do with port=0 is different
from what it means in the response. That makes it more complex. Its also
not backwards compatible, since this is not supported in rfc2543.
However, using the reINVITE mechanism I propose is backwards compatible. 

-Jonathan R.

---

From: "Rick Workman" <[email-masked]>
Date: Fri, 26 May 2000 10:29:01 -0400

I've been following this thread with interest because we're wrestling with a similar problem. So far I
like Jonathan's suggestion the best (setting "c" destination address to 0.0.0.0) because that seems to
be semantically consistent with the intent, i.e., start a session with a call leg (very briefly) on
hold. The only niggle is using a re-INVITE, which is a perfectly good solution in my mind, rather than
the ACK from the original INVITE. I note that the third party call control draft suggests that sending
the SDP in the ACK after an INVITE with no SDP content is OK, so I'm not sure why the same principal
wouldn't apply here. Am I missing something?

Rick Workman
Nortel Networks
Ottawa

---

From: Alberto Conte <[email-masked]>
Date: Fri, 26 May 2000 16:56:06 +0200

> However, using the reINVITE mechanism I propose is backwards compatible.

My point is: which is the behavior of a RFC2543 compliant SIP terminal when receiving
an INVITE message with the format that I proposed? 

I don't think this is defined. I think to something like "400 Bad Request" .

In such case I don't see any problem of backward compatibility. Terminals not
supporting the port=0 format should always reply with that error message. 

Alberto

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 26 May 2000 10:30:44 -0500 (CDT)

>media request delaying only the RTP port information in the ACK.

I'm going to have to go along with Lars and Jonathan here.
The power of SIP is in its generality. The tools defined with
the protocol as it stands today are flexible enough to allow
solutions to a wide variety of problems, including yours,
without requiring protocol changes (and complicated exception
cases in implementations) to handle special-case optimisations
like the one you propose.

For quite some time now, the SIP working group has been operating
under the premise that generality is far superior to optimisations.
It is an explicitly stated working group doctrine. I don't beleive
the situation you are describing is in any way special enough to
radically change our mode of operation.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA