[reSIProcate] UAC PRACK Support

[Byron Campen]

	Responses inline:

> 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

	When A gets the 183, the InviteSessionHandler will get an onEarly  
callback. If the implementation of
onEarly turns around and calls provideOffer(), this offer will be  
sent in the PRACK (at least, in theory).

> Now, A wants to send a new SDP Offer in PRACK for 183 - Is this  
> possible in present code ?
>
> 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 ?

	Is B dum also? If so, be informed that UAS 100Rel support isn't done  
yet. If you're wondering what A has to do in this case, everything  
should happen automatically; if the 180 carries an offer, A will get  
a handleOffer() callback, and if the 180 carries an answer, A will  
get the onEarlyMedia() callback. What A does from there is its own  
business. (For instance, part of the impl of handleOffer() would  
probably call provideAnswer(), whereas part of the impl of  
onEarlyMedia() would fire up RTP or whatever was negotiated).


Best regards,
Byron Campen

>
> 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
> > > >
> > >
> >
> >
>
> _______________________________________________
> 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/20070625/bcc5ecdb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070625/bcc5ecdb/attachment.bin>