Re: [reSIProcate] rejecting offer received to an SDP-less (re)INVITE

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Well - for the same reason (DUM doesn't look into the SDP contents) - it would be up to the application to examine the SDP received in the onAnswer callback and see if the media lines are rejected or not - it needs to do this anyway.  OnOfferRejected is currently only used for rejections at the Sip Message level (ie. 488 responses).

Scott

On Mon, Mar 19, 2012 at 6:26 AM, Robert Szokovacs <robert.szokovacs@xxxxxxxxxxx> wrote:

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