RE: [reSIProcate] reINVITEs
For reINVITEs all that you need to call is provideAnswer - there is no
control over provisional messaging. ReInvites are currently considered
by DUM to be "quick" transactions - since they should be immediately
responded to - thus there is no state change advertised to the
application.
You should inspect the SDP in the re-invite to see if the SDP session
info has changed - if so, then you should apply the new settings at the
same time you call provideAnswer.
Scott
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Fischl jason
Sent: Wednesday, August 10, 2005 1:29 PM
To: Christian_Gavin@xxxxxxxxxxxx
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] reINVITEs
In an early dialog, after calling provideAnswer you need to
subsequently call ServerInviteSession::provisional or
ServerInviteSession::accept to cause the message to go out. There are
some contexts where calling provideAnswer will immediately send out
signaling (where PRACK is involved)
On 8/10/05, Christian_Gavin@xxxxxxxxxxxx <Christian_Gavin@xxxxxxxxxxxx>
wrote:
> Hi,
>
> (Using DUM) When a reINVITE is received, and pSession->provideAnswer(
) is
> called, the call state transitions from receivedReinvite to connected,
but
> there doesn't seem to be any callback fired (eg. OnConnected).
>
> Is this the intended behavior ? If so, should the client restart
streaming
> with new parameters (eg. different codec, different remote IP, etc.)
right
> after calling provideAnswer( ) ?
>
> Thanks!
> CG
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel