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@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
> > >
> >
>
>
_______________________________________________ resiprocate-devel mailing list
|