Subject: RE: [Sip] Re: Offer by the callee

From: "Christer Holmberg (LMF)" <[email-masked]>
Date: Fri, 22 Mar 2002 01:26:39 +0100

Hi,

Are you talking about some kind of callback functionality? In that case I guess you would have to send some non-2xx response to the received INVITE, and then send a new INVITE with your offer.

But, I guess that's something you don't want to do.

I guess one possibility could be to return a 200, with the mode set to "inactive", and then (when you have received the ACK) send a re-INVITE, with a new set of codecs. Maybe not the most comfortable way of doing it, but...

I think the reason the rule, saying that the codec set in the answer must be a subset to the set in the offer, was to solve a number of problems, so I don't think we want to change that again...

Regards,

Christer Holmberg
Ericsson Finland

-----Original Message-----
From: [email-masked]
To: Gonzalo Camarillo
Cc: Jonathan Rosenberg; [email-masked]
Sent: 3/21/2002 5:09 PM
Subject: Re: [Sip] Re: Offer by the callee

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 <[email-masked]> on 21/03/2002
15:55:02

To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL
cc:   Jonathan Rosenberg <[email-masked]>, [email-masked]
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 [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: [email-masked]
Date: Fri, 22 Mar 2002 10:25:41 +0100

Hi Christer,

Thank you for your answer. A small clarification.
Please see the first mails on this thread, where I included a call flow
(I'm not including the entire set of exchanged mails, because somebody in
the list was very angry with that, and he is right).

First of all, the counter-offer possibility was not agreed, I'm not asking
to re-open the debate, I hope this is very clear now.
In the call flow I presented originally, I was using *strictly* the
offer-answer model. I don't think that I was using something forbidden in
the corresponding drafts (offer/answer, update, manyfolks); indeed, my main
purpose is to build scenarios using all these drafts.

My concern was only that, as the callee was receiving an offer, he doesn't
want to take it as is (even if he is obliged to provide an answer to this
offer), but he doesn't want to reject the session invitation either: he
knows that he will make a "better" offer.
The question, which is maybe more related to manyfolks was to give the
callee the possibility the indicate to the calling to not start  a useless
resource reservation because he wants to send a new offer.

Best regards
Juan Carlos

"Christer Holmberg (LMF)" <[email-masked]> on 22/03/2002
01:26:39

To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, "Gonzalo Camarillo Gonzalez
      (LMF)" <[email-masked]>
cc:   "'Jonathan Rosenberg '" <[email-masked]>, "[email-masked] '"
       <[email-masked]>
Subject:  RE: [Sip] Re: Offer by the callee

Hi,

Are you talking about some kind of callback functionality? In that case I
guess you would have to send some non-2xx response to the received INVITE,
and then send a new INVITE with your offer.

I guess one possibility could be to return a 200, with the mode set to
"inactive", and then (when you have received the ACK) send a re-INVITE,
with a new set of codecs. Maybe not the most comfortable way of doing it,
but...

I think the reason the rule, saying that the codec set in the answer must
be a subset to the set in the offer, was to solve a number of problems, so
I don't think we want to change that again...

Regards,

Christer Holmberg
Ericsson Finland