Re: [reSIProcate] UAC PRACK Support
On 6/14/07, Nilay Tripathi <nilay.linux@xxxxxxxxx> wrote:
Hi,
I was just going through the PRACK code, for UAC, in the "main". I want to
share some views about the level of control we can provide to the
application layer from DUM, in wake of the SDP negotiation.
It looks like DUM would take care of its own of sending PRACK for a reliable
1xx using function sendPrackIfNeeded().
Even as a UAC only, the case where the application wants to send an SDP
Offer or an Answer in the PRACK is not possible currently. For this kind of
control, application layer should be able to trigger the PRACK (with or
without SDP) using appropriate APIs.
Sending PRACK is completely taken care of by the stack. The
application only enables reliable provisional responses.
If the application (TU) calls InviteSession::provideOffer in an early
dialog, the stack will use PRACK, 200/OK or UPDATE as needed to
transport the offer.
Also, the application should be able to choose the method to use
(UPDATE/Re-INVITE) for sending a new SDP Offer.
The use of UPDATE vs re-INVITE is handled by the stack. If you enable
the UPDATE method and the peer supports UPDATE, dum will use UPDATE
instead of reINVITE.
I would appreciate your thoughts on this.
Thanks 'n' Regards,
Nilay
On 6/10/07, Derek MacDonald <derek@xxxxxxxxxxxxxxx> wrote:
> I merged UAC PRACK support in to main; see MasterProfile.hxx for
> "documentation". I also reverted the Security change which allowed
> server auth to be disabled. I'll be off net for a couple of weeks, but
> more documentation/etc. when I get back.
>
> -Derek
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel