Re: [reSIProcate] UAC PRACK Support
Hi,
Usage of UPDATE or re-INVITE by DUM looks fairly good !!
But still I think the control of PRACK (only for an SDP Offer) should come to application layer.
I am talking in context of rfc 3312 where on receiving an answer in reliable 1xx, the PRACK for 1xx can carry a new SDP offer right away.
Looking at the code it does not look possible as of now. On receiving a reliable 1xx with SDP answer, DUM will send PRACK. We should be able to provide the opportunity to provide an SDP Offer in the callbacks preceded by sendPrackIfNeeded to carry SDP Offer also in PRACK just like sendPrack() SDP Answer for reliable 1xx SDP Offer.
>> 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.
I do not think that anytime the SDP Offer is going in a PRACK.
>> The application only enables reliable provisional responses.
I am still trying to figure out how can I enalble a reliable provisional response with a Requires:100rel in the message. In the MasterProfile, 100rel is added as Supported and not Requires. So how as a UAS can I set Requires:100rel in 1xx.
My idea was that if we can have some argument in the provisional() API, similar to SDP inclusion for this.
Thanks 'n' Regards,
Nilay
On 6/15/07,
Jason Fischl <jason@xxxxxxxxxxxxxxx> wrote:
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
>