Subject: RE: [Sip] Question on manyfolks 05

From: "Chen, Xin (Xin)" <[email-masked]>
Date: Thu, 7 Mar 2002 14:12:47 -0000

Hi Christer and Gonzalo,

Thanks for your responses.

I think the "MAY" in 100rel drafte is perfectly fine here.  PRACK carries
offer can be very useful. Becuase for example, to sovle the 1 of N codecs
problem, I mean if the answer in 183 has multiple codecs for single media,
then the PRACK can be used to narrow them to one, and it is not likely
rejected by other peer.

Even if it is rejected by 415, the UAC can learn the reason from 415 and try
again.

Xin Chen

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

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: 07 March 2002 8:03
To: Gonzalo Camarillo
Cc: Chen, Xin (Xin); [email-masked]
Subject: Re: [Sip] Question on manyfolks 05

Hi,

> >In section 11,
> >
> >None of the examples shows the PRACK/200 following the INVITE/183 as a
new
> >offer/answer exchange, but I think this is allowed, am I right?
>
> The PRACK can carry an anwer. About a PRACK carrying an offer, it should
> not be done, because you would not have a way of refusing the offer
> without refusing the PRACK itself.

Chapter 5 in 100rel says:

"If the UAC receives a reliable provisional response with an answer, it MAY
generate an
additional offer in the PRACK. If the UAS receives a PRACK with an
offer, it MUST place the answer in the 2xx to the PRACK."

"MAY" does not mean the same as "SHOULD NOT". Do we need a change in the
text?

However, IF the UAC receives a PRACK, with an offer it does NOT accept, what
about sending a 2xx response to the PRACK, and a 415 response to the INVITE?
Does it really matter if it refers to the session description in the INVITE,
or
in the PRACK, since the session setup has failed?

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
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: Fri, 08 Mar 2002 05:20:54 +0200

Hi,

A PRACK for a 1xx response that contained an answer can contain an offer
(as stated in the draft), because the UAS will not generate an UPDATE
until it receives the PRACK... therefore, in that situation, there is
not a chance of having a glare condition... it is OK as it is specified.

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]

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 08 Mar 2002 10:35:06 +0200

Hi,

> not a chance of having a glare condition... it is OK as it is specified.

I guess the issue is still what the UAS shall do if it doesn't accept the offer in
the PRACK.

Xin Chen's proposal was to send a 415 for the PRACK, and the UAC MAY then send a
new PRACK. The problems with that proposal, as I see it, are the following:

1. This would be against the semantics of PRACK.

2. Since the UAS doesn't know if there will be a new PRACK or not, it doesn't know
if it should "buffer" a possible 200 final response to be sent.

I would also like to bring up a 200 rece condition scenario:

If the UAS receives an offer in the PRACK, it must send the answer in the 200 to
the PRACK. At the same time, however, it may send a 200 to the INVITE. And, the
200 for the INVITE MAY reach the UAC BEFORE the 200 for the PRACK. Now, that would
mean that the UAC would have to "buffer" the 200 until it receives the the 200 for
the PRACK, since it needs the answer which will be included in the 200 to the
PRACK....

Regards,

Christer Holmberg
Ericsson Finland