Thanks for answering this Brett.
Just to elaborate a bit, RFC 3262 says:
If the PRACK does match an
unacknowledged reliable provisional response, it MUST be responded to
with a 2xx response.
It did not contemplate a situation when there were reasons to reject it
in this case. And it is problematic to do so, since it affects the
timing of INVITE.
On the other hand, there *are* reasons that the you *can't* respond with
a 2xx. (One example would be if the prack contains credentials that are
incorrect.)
But in 6337 we suggested behaviors that were in accord with the
normative requirements of 3262, even if they are not ideal.
To avoid this kind of situation, you should be careful of what you put
into an offer in a prack - only things that are necessary to complete
the INVITE transaction. For instance, if the initial offer had
preconditions, then the subsequent offer would presumably be to indicate
progress on those preconditions. Don't do something stupid, like
offering codecs that are inconsistent with those in the first offer.
Then you won't have created a situation that must be rejected.
Thanks,
Paul
More inline
On 7/11/12 8:26 AM, Brett Tate wrote:
> Hi Kamini,
>
> Reply inline.
>
>> RFC 6337 says:
>> 5. PRACK Req. (**) 200 PRACK Resp. followed by new offer
>> OR termination of dialog
>>
>> If offer in PRACK is rejected then UAS should respond
>> with 200 OK followed by BYE(i.e. termination of dialog)
>> or new offer.
>
> If the termination of early dialog is done by receiver of the PRACK, it is
> not done by sending BYE. It is done by sending an INVITE failure response
> such as 487.
>
>
>> Let say, we opt for terminating the dialog.
>
> <snip>
>
>> Is this the correct behavior to implement or should
>> we reject only PRACK and dialog should not get impacted?
>
> If you follow the RFC 6337's recommendation, you cannot reject the PRACK.
>
> However if you reject PRACK with 488 (per the RFC 6337 open issue), it might
> allow the dialog to remain or it might cause the UAC to release the call or
> dialog (per their RFC 3262 interpretation or because they prefer to CANCEL
> the INVITE or BYE the specific early dialog).
>
> The following is one of many threads discussing the 488 open issue.
>
> http://www.ietf.org/mail-archive/web/sipping/current/msg15146.html
>
>
> The following is the RFC 6337 "**" text highlighting the hope that you will
> not have to reject a PRACK's offer.
>
> "(**) A UA should only use PRACK to send an offer when it has
> strong reasons to expect the receiver will accept the offer."
>
>
> _______________________________________________
> 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
