[reSIProcate] UAC PRACK Support

[Derek MacDonald]

Inline.

On 6/17/07, Nilay Tripathi <nilay.linux at gmail.com> wrote:
> Hi,
>
> I think I didn't put my queries the correct way. So here it goes again:
>
> Problem #1:
> A(dum) is UAC, B is UAS
>
> A sends INVITE with SDP Offer
>  B sends reliable 183 with SDP Answer
> Now, A wants to send a new SDP Offer in PRACK for 183 - Is this possible in
> present code ?
>
No. DUM will send use UPDATE to for O/A exchanges in the early dialog
one the 18xrel/PRACK exchange has been completed. Consequently, the
UAS must support update for DUM to re-offer in the early dialog.

> Problem #2
> A(dum) is UAC, B is UAS
>
> A sends INVITE with Supported: 100Rel
> B wants to send 180 with Requires: 100Rel - How do we do this ?
>
> Thanks for your patience :)
>
> Regards,
> Nilay
>
>
> On 6/15/07, Jason Fischl <jason at counterpath.com> wrote:
> > I don't think you're right.
> >
> > A(dum) is UAC,  B is UAS
> >
> > A sends INVITE with no offer
> > B sends 180 with offer
> > A get callbacks, onNewSession, onProvisional, onEarly
> > in onEarly callback, A should call provideAnswer which will cause a
> > PRACK to be sent with the answer in it.
> >
> > I didn't test this behavior but looking at the code and the state
> > diagram, this is what it looks like it will do to me.
> >
> > On 6/15/07, Nilay Tripathi < nilay.linux at gmail.com> wrote:
> > > 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
> > > > >
> > > >
> > >
> > >
> >
>
>