Re: [reSIProcate] rejecting offer received to an SDP-less (re)INVITE
Currently DUM does not have any special logic in it to do any SDP offer/answer negotiation, besides notifying the application. In fact it just treats SDP bodies entirely transparent, and leaves all handling of media lines, etc. to the application. If you want an answer to be sent with media line ports set to zero (to be compliant to 6337), you can't use the reject API - you would need to build your own rejection SDP and then use provideAnswer to have it sent with the ACK - then later BYE/end the session. I can see you will likely run into issues trying to know when to call reject vs provideAnswer for re-invite scenarios.
Scott
On Wed, Mar 14, 2012 at 8:03 AM, Robert Szokovacs
<robert.szokovacs@xxxxxxxxxxx> wrote:
On 2012 Mar 14, Wed 11:40:39 Robert Szokovacs wrote:
> Hi,
>
> According to RFC 6337 section 5.2.4:
>
> Because the offer arrives in a response to the INVITE, the UAC cannot
> reject the message containing the offer. If the UAC wishes to reject
> the entire offer, it must send a PRACK or ACK request including all
> the media lines with ports set to zero. Then, if it does not wish to
> continue the session, it may send a CANCEL or BYE request to
> terminate the dialog.
>
> But if I understand the code correctly, reSiprocate sends the ACK without
> sdp: resip/dum/InviteSession.cxx:760 in InviteSession::reject
>
> // Sent a reINVITE no offer and received a 200-offer.
> // Simply send an ACK without an answer and stay in Connected.
> case SentReinviteAnswered:
> {
> InfoLog (<< "Not sending " << statusCode << " error since
> transaction"
> "already completed, sending answer-less ACK");
> transition(Connected);
> sendAck();
> break;
> }
>
> Also, upon receiving the ACK, in
> InviteSession::dispatchReceivedReinviteSentOffer, the cases OnAckAnswer and
> OnAck are distinguised, only by the existence of the SDP, not by its
> contents.
>
> Is this a known bug? I could not find the relevant information in earlier
> RFCs so maybe the code follows an older (or newer?) standard :)
If the initial offer is in the first reliable non-failure
message from the UAS back to UAC, the answer MUST be in the
acknowledgement for that message (in this specification, ACK
for a 2xx response).