[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] rsvp or manyfolks in 3gpp
See in line please.
Xin Chen
Lucent Technologies
Tel: +44 1793 883137
Mobile: +44 7799 034668
-----Original Message-----
From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
Sent: 16 March 2002 6:29
To: xchen2@lucent.com
Cc: sip@ietf.org
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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip