[reSIProcate] UAC PRACK Support

[Nilay Tripathi]

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 at counterpath.com> wrote:
>
> On 6/14/07, Nilay Tripathi <nilay.linux at gmail.com> 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 at counterpath.com> 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 at list.resiprocate.org
> > >
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> > >
> >
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel at list.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/20070615/fadf86f6/attachment.htm>