Re: [reSIProcate] rejecting offer received to an SDP-less (re)INVITE
On 2012 Mar 14, Wed 09:58:47 Scott Godin wrote:
Hi,
> 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.
This is the smaller problem, the bigger one is when _receiving_ an ACK with
ports set to zero, the callback called is onAnswer() when it should be
onOfferRejected().
br
Szo
>
> 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 :)
> >
> > I found it in RFC 3261:
> > 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).
> >
> > br
> >
> > Szo
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxx
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel