[reSIProcate] Multiple provisional with the same SDP: bug or feature?

[Scott Godin]

What do you mean by "the second message"?

Scott

On Thu, Sep 16, 2010 at 10:13 AM, Robert Szokovacs <
rszokovacs at gammatelecom.hu> 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 at gammatelecom.hu> 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 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/20100916/e56df90d/attachment.htm>