Re: [reSIProcate] UAC PRACK Support
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 ?
Problem #2A(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
> > >
> >
>
>