Re: [reSIProcate] Multiple provisional with the same SDP: bug or feature?
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).
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-devel