< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] UAC PRACK Support


Inline.

On 6/17/07, Nilay Tripathi <nilay.linux@xxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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@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
> > > >
> > >
> >
> >
>