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

[Scott Godin]

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 at gamma.co.uk> 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 at gamma.co.uk> 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 at resiprocate.org
> > > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20120319/022c3ce4/attachment.htm>