Szo
>
> Scott
>
> On Thu, Sep 16, 2010 at 2:47 PM, SZOKOVACS Robert <
>
>
rszokovacs@xxxxxxxxxxxxxxx> wrote:
> > On 2010. September 16., Scott Godin wrote:
> > > What do you mean by "the second message"?
> >
> > First, there is a 183 with SDP then a 180 without. The problem is even
> > if I send the 180 with earlyFlag=false, the SDP from the 183 will be
> > in the message.
> >
> > br
> >
> > Szo
> >
> > > Scott
> > >
> > > On Thu, Sep 16, 2010 at 10:13 AM, Robert Szokovacs <
> > >
> > >
rszokovacs@xxxxxxxxxxxxxxx> wrote:
> > > > Hi again,
> > > >
> > > > I used the earlyFlag, and resiprocate still included the SDP in the
> > > > second message. It was because the m1xx SipMessage is never reset,
> > > > only updated in ServerInviteSession::sendProvisional(). I think the
> > > > solution would be to call
> > > > releaseContents() in case of false earlyFlag. Should I create a
> > > > patch?
> > > >
> > > > br
> > > >
> > > > Szo
> > > >
> > > > On 2010 September 16, Thursday 10:22:05 Robert Szokovacs wrote:
> > > > > On 2010 September 15, Wednesday 18:43:18 Scott Godin wrote:
> > > > > > There is a parameter to the provisional method, called
> > > > > > earlyFlag, that specifies if you would like the SDP to be
> > > > > > provided in the 18x response
> > > >
> > > > or
> > > >
> > > > > > not (if you happened to provide the SDP to resip before calling
> > > > > > this).
> > > > >
> > > > > My bad, I was sidetracked by the comments in the header and
> > > > > failed to realize there's already a solution :(
> > > > >
> > > > > Thank you for the answer!
> > > > >
> > > > > br
> > > > >
> > > > > Szo
> > > > >
> > > > > > If you are not using PRACK then any SDP send in a 18x response
> > > > > > must
> > > >
> > > > also
> > > >
> > > > > > be repeated in the 200 response, and it cannot be changed -
> > > > > > this is an RFC requirement.
> > > > > >
> > > > > > Scott
> > > > > >
> > > > > > On Wed, Sep 15, 2010 at 10:31 AM, Robert Szokovacs <
> > > > > >
> > > > > >
rszokovacs@xxxxxxxxxxxxxxx> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > We have a B2BUA based on resiprocate and we noticed that if
> > > > > > > the "c" leg (the
> > > > > > > one we call out to) sends a 183 with SDP and then a 180
> > > > > > > without, we pass the
> > > > > > > "a" leg (the one originated the call) the 180 with the SDP
> > > > > > > from the
> > > >
> > > > 183
> > > >
> > > > > > > included. This is not the desired behaviour, since there are
> > > > > > > some 3rd party devices that doesn't seem to tolerate this.
> > > > > > > This happens because we call ServerInviteSession's
> > > > > > > provide[Answer|Offer]() before calling provisional() for the
> > > > > > > 183, and then calling provisional() for
> > > > > > > the 180, and have no way of telling resiprocate not to
> > > > > > > include the
> > > >
> > > > SDP.
> > > >
> > > > > > > The problem is that according to the comments in
> > > > > > > ServerInviteSession.hxx it is not
> > > > > > > necessary:
> > > > > > > /** Called to set the offer that will be used in the next
> > > > > > > message
> > > >
> > > > that
> > > >
> > > > > > > sends an offer. [...] */
> > > > > > >
> > > > > > > virtual void provideOffer(const SdpContents& offer);
> > > > > > >
> > > > > > > (same with provideAnswer)
> > > > > > >
> > > > > > > We interpreted it as "the next and only the next" message
> > > > > > > will
> > > >
> > > > include
> > > >
> > > > > > > the SDP, but the code doesn't do that way. Is that the
> > > > > > > correct behaviour? If it's
> > > > > > > a bug, which way should I look for solution? Should we empty
> > > > > > > the mCurrentLocalSdp & mProposedLocalSdp after sending it?
> > > > > > > Should we transition to
> > > > > > > a state that doesn't call setSdp() in sendProvisional()
> > > > > > > (which
> > > >
> > > > state?)
> > > >
> > > > > > > Any help is appreciated!
> > > > > > >
> > > > > > > TIA
> > > > > > >
> > > > > > > br
> > > > > > >
> > > > > > > Szo
> > > > > > > _______________________________________________
> > > > > > > resiprocate-devel mailing list
> > > > > > >
resiprocate-devel@xxxxxxxxxxxxxxx
> > > > > > >
https://list.resiprocate.org/mailman/listinfo/resiprocate-dev
> > > > > > > el