[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Remaining offer/answer issue: how to reject an SDPoffer sent in PRACK
Christer,
Forgot about the compatibility issues of changing the sdp offer/answer
with PRACK.
488 appears to be the best way forward then.
Ian Elz
System Manager
DUCI LDC UK
(Lucid Duck)
Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz at ericsson.com
-----Original Message-----
From: Christer Holmberg
Sent: 28 August 2008 10:12
To: Ian Elz; 'Paul Kyzivat'
Cc: 'sipping LIST'
Subject: RE: [Sipping] Remaining offer/answer issue: how to reject an
SDPoffer sent in PRACK
Hi Ian,
I think not allowing SDP in PRACK is too late at this stage.
PRACK is used to carry SDP at least in preconditions scenarios, and
there are also non-IETF SDOs which have defined such procedures. Not
allowing SDP in PRACK would require big changes, in a number of
different places.
I think the good thing with the 488 proposal is that the SDP offer would
be rejected in exactly the same way as when carried in any other type of
SIP request.
We DO need to figure out the issue how to make sure the UAC knows
whether the reliable provisonal response has been acknowledged, but
unless there are any objections I would propose that we move forward
with the 488 proposal and then start looking into the details.
Regards,
Christer
-----Original Message-----
From: Ian Elz
Sent: 28. elokuuta 2008 10:56
To: Christer Holmberg; Paul Kyzivat
Cc: sipping LIST
Subject: RE: [Sipping] Remaining offer/answer issue: how to reject an
SDPoffer sent in PRACK
Paul, Christer,
I liked one of the original ideas. PRACK not being used for
offer/answer.
I would modify it though to allow an sdp answer in the PRACK but not an
offer.
This would allow an INVITE with no sdp to be sent with the sdp offer in
the provisional response and the answer in the PRACK. (I think that this
is essential for preconditions where the empty INVITE is sent e.g. 3PCC)
The approach would also resolve one of the preconditions queries.
Does it make sense for a confirmed offer to be sent in a PRACK?
Theoretically it does but whether it would ever happen in practice is
another matter.
Ian Elz
System Manager
DUCI LDC UK
(Lucid Duck)
Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz at ericsson.com
-----Original Message-----
From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On
Behalf Of Christer Holmberg
Sent: 28 August 2008 07:01
To: Paul Kyzivat
Cc: sipping LIST
Subject: Re: [Sipping] Remaining offer/answer issue: how to reject an
SDPoffer sent in PRACK
Hi Paul,
>>>There are no perfect choices here.
>>>
>>>What is wrong with just returning any appropriate error response -
e.g. 488?
>>>
>>That is the second alternative in my list.
>>
>>>The main problem with that is whether it did/didn't ack the response.
>>>After considering alternatives, ISTM that this should then also mean
>>>that the reliable response has not yet been acknowledged, and so
>>>another PRACK must be sent - preferably one without an offer.
>>
>>...or, we could define that a 488 must not be sent for PRACK unless
the reliable response was acknowledged.
>
>I thought about trying to classify responses as to whether they imply
that the response has been acked or not. (Obviously 200 does. You are
proposing that 488 should. Most likely there would be
>others.)
Or, as I suggested, instead of the response code we use the RSeq header
to indicate whether the response has been acked or not. Maybe that would
be more "safe".
>>But, I guess one potential issue with that is that if is an
intermediate, and not the endpoint sending the reliable responses, which
sends the 488 then the reliable responses will keep coming
>>(since the endpoint sending the reliable responses never got the
PRACK).
>
>Allowing intermediates (proxies) to send reliable responses is a
*terrible* idea. I thought we had already excluded that.
What I meant was that a UAS is sending the reliable response. But, then
an intermediate rejects the PRACK with 488 (because it contains an offer
the intermediate doesn't like). In this case the UAS will keep
re-transmitting the reliable response, so the UAC will have to send a
new PRACK (without SDP).
>I propose it is better for the UAC to assume that any failure response
to a PRACK requires a new PRACK to be sent to ack the response.
But, what IF the first PRACK actually acknowledged the reliable
response? In that case I guess the UAS may send a 481 to the second
PRACK? Will the UAC just accept it and "move on"?
But, in any case, I will document this send-a-new-PRACK-without-SDP as
one option.
>>Maybe we could specify that the RSeq header shall be included in the
PRACK response, to indicate that the relaible response has NOT been
acknowledged yet?
>
>???
>
>So you are suggesting that something special be added to a non-200
PRACK response to acknowledge the PRACK while rejecting it?
Yes. Today, neither RSeq nor RAck are inserted in the PRACK response.
So, an RSeq in the non-200 PRACK response would have the same meaning as
in a reliable provisional resonse: "Hey, this is the seq number you have
to send a PRACK for".
Regards,
Christer
> Regards,
>
> Christer
>
>
>
>
>
>
>
> Thanks,
> Paul
>
>> Personally I don't see a
>> make-sure-you-send-an-offer-which-will-not-be-rejected alternative as
>> feasible, because the UAS may want to reject the offer based on other
>> circumstances (e.g. overload).
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP Use
>> sip-implementors at cs.columbia.edu for questions on current sip Use
>> sip at ietf.org for new developments of core SIP
>
>
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sip at ietf.org for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP