Subject: RE: [Sip] Manyfolks version 04

From: "Chen, Xin (Xin)" <[email-masked]>
Date: Tue, 26 Feb 2002 13:47:38 -0000

The question I have in mind is why we need "local" and "remote" here.

"a=des:qos mandatory local sendrecv" generated by the offerer has no meaning
to the answerer, because this is something that the answerer can not help,
because this is your(offerer's) network not mine(answerer's)!

And "a=des:qos mandatory remote sendrecv" generated by the offerer has the
same meaning as "a=des:qos mandatory e2e sendrecv" from the anserer's point
of view.

I think only "e2e" is needed. Because as a user, I don't care what local
access network another end is using, actually I even don't know what
protocol the other end is using for QoS, what I want is end to end QoS for
my the video or audio streams. Therefore, it is up to the user agent to
intercept and decide whether e2e condition is met or not.

For example, if the answerer receives an offer requiring e2e QoS sendrecv,
but the answerer only supports local network QoS protocol and uses Differv
in the core network to provide end to end QoS, therefore this call should
not fail just because the answerer doesn't support RSVP. So answerer just
needs to finish the local network QoS reservation and ACKs the offerer that
e2e is met. In a word, for the answerer's point of view, "e2e"="remote".

If an offerer doesn't support e2e QoS protocol, it can still put "e2e" in
its offer, because from the offerer's point of view, "e2e"="local".

Thanks

Xin Chen

Lucent Technologies
Tel: +44 1793 883137
Mobile: +44 7799 034668

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 26 February 2002 3:03
To: sip
Cc: Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott;
[email-masked]; Jonathan Rosemberg
Subject: [Sip] Manyfolks version 04

Hello,

I have just submitted a new version of the manyfolks draft. Until it
appears in the archives, you can fetch it from:
http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.pdf

http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.txt

About the authorship of this draft, the ADs and the WG chairs decided
that all the coauthors of previous versions but Bill had to be moved to
a Contributors Section.

The deadline for this draft is very close, so I would appreciate that
folks read the draft and send comments as soon as possible.

I have removed security preconditions (per mailing list discussion), but
added a token that can be used to define new precondition types (the
only type currently defined is "qos").

The draft uses two attributes: desired-status and current-status. When
the current status reaches (or goes beyond) the desired status the
preconditions are met. Instead of defining an absolute ordering for
these two attributes, I have defined status tables. They are
abstractions of the preconditions carried in the SDP. These tables help
explain how status synchronization between both user agents is performed
and when exactly all the preconditions are met.

Feedback is appreciated,

Best regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 26 Feb 2002 17:52:40 +0200

Hello,

> because this is your(offerer's) network not mine(answerer's)!

The concept of e2e qos has been present in this draft since the
beginning. We have now introduced the new segmented type, which includes
the tags you are referring to (local and remote).

If I (the offerer) reserve network resources for the media stream in my
local interface and then send you the INVITE, you are right that this
information may be considered useless for the answerer. However, I might
want to, first send the INVITE and see if the answerer is willing to
establish a session using qos. If the answerer responds to my INVITE
accepting my mandatory preconditions, I can begin reserving resources in
my local interface. In this case, I need a way to communicate the
answerer that I am done with my local interface. That's why we need both
tags.

> same meaning as "a=des:qos mandatory e2e sendrecv" from the anserer's point

No, they don't. If I am a 3GPP terminal, establishing the appropriate
PDP context will meet the first precondition, but not the second.

The e2e type is intended for e2e reservation protocols (this is stated
in the draft, by the way).

> my the video or audio streams.

OK, so you will always use e2e qos. But other folks find it useful to
have the segmented type... although this does not mean that you have to
use it.

Thanks for your comments,

Gonzalo

>Therefore, it is up to the user agent to