Subject: SIP equiv of H.323/225 messages

From: Barbara M DeSutter <[email-masked]>
Date: Fri, 1 Oct 1999 17:44:17 -0700 (MST)

Hi,

Does anyone know the SIP equivalent to the H.323/H.225 Address Confirmation
(ACF) and Admission Request (ARQ) messages?

Thanks,
Barb

-- 
Technical information contained here is exportable under ECCN5E992 NLR.

Barbara DeSutter        Email: [email-masked] or [email-masked]
Motorola - CIG          Phone: 480-441-1200
AZ25 - H707             Pager: 1-800-759-8888 (PIN 1372422)
8201 E. McDowell Rd.    Fax:   480-675-2434
Scottsdale, AZ 85252

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 2 Oct 1999 13:47:00 -0400

Barbara,

SIP does not have the concept of a network-centric "gatekeeper" like H.323,
and thus has no need for such messages.  SIP starts a call with INVITE,
which equates to an H.323 SETUP.

However, some groups are insisting on killing the "simple" SIP protocol by
adding complexity necessary to support PSTN networks and bill for calls.
H.323 has been flamed for this complexity... so why these independent SIP
groups are doing this just isn't rational.

It is important to be aware that there are at least two groups who are
mutilating SIP, in my opinion.  One is pushing SIP BCP ("Best Common
Practices", formerly SIP+) and the other is pushing SIP DCS ("Distributed
Call State").  Neither are completely interoperable and DCS just completely
breaks away from the SIP ideology.

Best Regards,
Paul

----- Original Message -----
From: Barbara M DeSutter <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 01, 1999 8:44 PM
Subject: SIP equiv of H.323/225 messages

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 02 Oct 1999 14:43:18 -0400

ACF is Admission Confirm, not Address Confirm. In any case, the BRQ/ARQ
message sets are not present in SIP, as has been pointed out. As the
media paths and signaling can be completely separate (imagine yahoo
providing SIP services, but media transport is provided by the users
internet service provider), in many (actually, most) cases, the SIP
server will not have sufficient information to usefully perform
admission control for calls based on network capacity. I have argued
that the same is true for a gateekeper. This function is best delegated
to COPS servers, bandwidth brokers, and other devices which provide
cross-application QoS services.

However, a SIP server can perform "admission control" based on policy.
Its quite simple. When the INVITE arrives at a proxy, it can simply
reject the request if the server policy determines that the call is not
allowed to be initiated. Since the SDP in the SIP INVITE conveys codec
information, one might even reject calls based on the total amount of
bandwidth used by all calls initiated through the proxy. This isn't
going to be all that useful for controlling network resource usage, but
it is allowable from a pure policy perspective. 

-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: Henry Sinnreich <[email-masked]>
Date: Sun, 03 Oct 1999 09:30:25 -0500

> breaks away from the SIP ideology.

Let's see the bottle as half full. The internal implementations exemplified
by Paul validate SIP in the sense that if anyone wants to build a service
delivery architecture, would chose SIP. I also agree with Paul in the sense,
that all ships will rise with the tide if we develop complete specifications
for global interoperability. The newly formed SIP working group has its work
cut out for this purpose. Please see the attached.

Henry

From:	Media Gateway Control (megaco) [[email-masked]]
on behalf of Jonathan Rosenberg [[email-masked]]
Sent:	Tuesday, September 28, 1999 11:27 AM
To:	[email-masked]
Subject:	[Fwd: WG ACTION: Session Initiation Protocol (sip)]

Folks,

My apologies for the broad cross-posting, but I wanted to make sure
folks see this.

As those who attended mmusic in Oslo may recall, there was agreement
that the work of mmusic was becoming too much. In particular, the SIP
related activities were enough to warrant its own group. The mmusic
session devoted some time to deciding on what a new group would look
like. It was agreed that such a group SHOULD NOT focus on pure IP
telephony aspects of SIP, but rather its broadest application. As such,
a new sip working group has been formed. its charter is to fully own
SIP, including its movement to draft, and any extensions which may
arise. It is within the charter that maintaining the generality and
broad application of SIP, and keeping it simple, are primary goals of
the groups activity. Note that the email below is incorrect regarding
the area; the sip working group is within the transport area.

From here on, we would like to use the sip mailing list
([email-masked]) for SIP related discussion. mmusic is
still active, and is going to continue work on sap, sdp, rtsp, and those
non-SIP things. As such, please use the mmusic list ([email-masked])
for discussion of those issues.

*************************************
NOTE: YOU WILL NOT BE AUTOMATICALLY SUBSCRIBED TO THE SIP MAILING LIST.
YOU MUST SUBSCRIBE YOURSELF USING THE PROCEDURES ON THE SIP WEB PAGE
http://www.bell-labs.com/mailing-lists/sip/

WHICH SAYS TO SEND MAIL TO [email-masked] WITH
THE SINGLE WORD
subscribe IN THE BODY

DO NOT SEND SUBSCRIPTION REQUESTS TO [email-masked] OR
[email-masked]
*************************************

Thanks,
Jonathan Rosenberg
Joerg Ott
Dean Willis
sip co-chairs

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Paul E.
> Jones
> Sent: Saturday, October 02, 1999 12:47 PM
> To: Barbara M DeSutter; [email-masked]
> Cc: [email-masked]
> Subject: Re: SIP equiv of H.323/225 messages
>
>
> Barbara,
>

---------