Re: [Sip] Re: Offer by the callee

[Juan-Carlos.Rojas@alcatel.fr]

Hi,

Alice's phone can be pre-prgrammed to use a normal codec, so the terminal
will not announce (by default) the high-quality codec (because of any
reason, and among others, because it is very likely that when using this
high-quality codec, the whole communication will be more expensive). She is
sending a normal Invite, not necessarily announcing her capability set.
If the terminal announces systematically the entire set of capabilities, it
is very likely that the answerer will always pick up the highest quality
one, with which the communication will be the most expensive. You see that
in this case, Alice is "unable" to control her expenses.
Therefore, when Bob sends the bunch of extra codecs, the high-quality one
will be surely in the first position, so it is very likely that Alice will
use it (except obviously if her terminal does not support such feature).

Where I'm a little bit worried with the basic Offer/Answer model (since the
counter-offer possibility was never agreed), is that finally, as you say in
the mail below, it is very "Offerer-oriented", that is, if the Answerer
wants to make a new offer, he is obliged to accept/reject the current offer
before.
This is not a problem with mid-session offers, since even if the answerer
rejects the offer, the session will always come back to the state prior to
the offer (which can be assumed to be a known state), so giving the
answerer the possibility to generate next a new offer.

The main concern is dealing with the first session description agreement,
and therefore the first resource reservation procedure, as is the case of
my example.
Indeed, this possibility has been given to the Offerer, with the new 155
provisional response, which means "Mr. the Offerer, I'm not rejecting the
session invitation, but I'm not really happy with the session description,
so please provide a new offer in an UPDATE message"

Best regards
Juan Carlos





Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se> on 21/03/2002
15:55:02

To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL
cc:   Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@ietf.org
Subject:  Re: [Sip] Re: Offer by the callee


Hi,

The situation you are describing does not sound very sensible, because
if Alice offers a set of codecs, it is because she wants to use that set
of codecs. Therefore, even if Bob sends her an offer with a bunch of
extra codecs, the possibilities that Alice sticks to her first offer are
very high. Well, if she is using some kind of capability announcement
Bob could know that she supports the high quality codec...

About the video stream, the QoS reservation will begin when the second
offer is sent, so it does not represent any problem.

So, even if Alice uses simcap, for instance, and Bob will offer a new
codec in an extra offer, it is a good idea to start resource reservation
as soon as possible. Just in case Alice refuses the second offer.


I understand you scenario, but it does not fit very well with the
offer/answer model. In the offer/answer model, I send you an offer, and
if you accept it, we have a session. If not, we don't. You are now
saying that you do not want to accept the session, but that if the offer
was different, you would be willing to accept it... that's why you may
have to wait a RTT before you send the second offer.

Anyway, if you really want to express that, you can always set your
ports to zero, although I do not think it is a very good idea.

Regards,

Gonzalo





_______________________________________________
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