Paul Kyzivat wrote:
>
> [EMAIL PROTECTED] wrote:
>> From: Paul Kyzivat <[EMAIL PROTECTED]>
>>
>> [EMAIL PROTECTED] wrote:
>> > From: "Rayees Khan" <[EMAIL PROTECTED]>
>> >
>> > It is not always the case. In case there are offer-answer exchanges
>> with
>> > PRACK and UPDATE before 200 OK is sent, having SDP in 200 OK same as
>> 183
>> > is not a good idea.
>> >
>> > Perhaps it is a bad idea, but it is *required* -- SDP sent in a
>> > provisional response must be duplicated in the final response (if it
>> > is a success response).
>>
>> Careful Dale. It is required if the early answer was *unreliable*. If
>> the early answer was in a *reliable* 18x, then its repeat in 200 is
>> *optional*. I agree in that case that it is a bad idea to include it,
>> but it is allowed.
>>
>> Oops, my mistake.
>>
>> I assume that the obligation of the UAS to put the SDP in the 200 is
>> removed when it receives a PRACK of a provisional response that had
>> SDP? That is, if it *doesn't* get PRACKs that it expects, it must put
>> the SDP in the 200.
>
> I'm not certain it would even get that far. If it has sent a 1xx with
> 100rel and it doesn't receive a PRACK in response, then I think it will
> abandon the call at that point. (Though the proper way to abandon the
> call isn't entirely clear to me.)
From RFC 3262:
The UAS MAY send a final response to the initial request before
having received PRACKs for all unacknowledged reliable provisional
responses, unless the final response is 2xx and any of the
unacknowledged reliable provisional responses contained a session
description. In that case, it MUST NOT send a final response until
those provisional responses are acknowledged. If the UAS does send a
final response when reliable responses are still unacknowledged, it
SHOULD NOT continue to retransmit the unacknowledged reliable
provisional responses, but it MUST be prepared to process PRACK
requests for those outstanding responses.
So no, it's not supposed to get that far. I wouldn't necessarily expect
many implementations to correctly delay the 2xx, though. Maybe a good
SIPit test case.
Anders
>
> If it decides to proceed as if the 1xx was unreliable then it would
> indeed presumably have to follow all the rules that accompany that decision.
>
> Paul
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
