Subject: RE: [Sip] rsvp or manyfolks in 3gpp

From: "Chen, Xin (Xin)" <[email-masked]>
Date: Mon, 18 Mar 2002 21:09:24 -0000

See in line please.

Xin Chen

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 16 March 2002 6:29
To: [email-masked]
Cc: [email-masked]
Subject: [Sip] rsvp or manyfolks in 3gpp

xin,

from your message i get an impression that rsvp is not mandatory in 3gpp
terminals:

[xc] Correct. RSVP or any other extra signalling protocol used for QoS
reservation which will cost radio resource will not be implemented in
terminals.

> I am familiar with the 3GPP SIP architecture, our terminals don't use
> RSVP, ...

last fall i wrote on the sip mailing list:

> i met yesterday a person who works for a big mobile phone/network vendor
> and when i asked about manyfolks, he said that the 3gpp indeed has
> adopted it, but that it is not a mandatory part of the spec and that
> this vendor has no intention to use it in its own products.

to which Miguel Garcia from ericsson replied:

> Good luck to that vendor. I can tell you that manyfolks IS mandatory
> in 3GPP, so if somebody designs a terminal that does not support
> manyfolks, is not going to be 3GPP compliant. I believe the person you
> spoke to is miss-informed.

[xc] Miguel was right that we need manyfolks because it provides the
precondition so that calling user can prevent the called user from ringing
until the calling user completes the PDP context activation. But this
doesn't mean that 3GPP terminals have to support any QoS reservation
protocol.

i'm now a bit buzzled here?  is it so that an e-2-e reservation
according to manyfolks is mandatory in 3gpp terminals, but the
reservation protocol doesn't need to be rsvp?  if so, can each handset
vendor invent their own or what?

[xc]Precondition is mandatory in 3GPP terminals, but not any QoS reservation
protocol. Only PDP context activation message will go to signalling channel
and free of charge, but if the terminal wants to use RSVP or something
similar, it is fine, but the RSVP messages will not be sent on signalling
channel but user traffic channel and get charged.

-- juha

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Mon, 18 Mar 2002 23:42:27 +0200

> doesn't mean that 3GPP terminals have to support any QoS reservation

that makes sense, but i still don't understand why anything beyond basic
sip is needed for this purpose.  why can't it be a standard behavior of
a 3gpp terminal always first try to setup a real time pdp context for
the media and send the invite or generate ringing only if the setup
succeeds?

-- juha