RE: [reSIProcate] DUM API question
Yuck.
So, 100 Trying is special (h-h) - ignore it for the rest of this
conversation.
For all other responses (provisional or not), the safest thing
to do is to think of a missing to tag as an "empty" to tag and
make a dialog that has that as part of its dialog identifier.
If more than one leg sends back responses with no to-tag, then
bad things will happen (and we'll just live with it) - that's why
the protocol grew to-tags in the first place.
I appreciate everyone taking the time to get this stuff right.
It's detail rich. Keep in mind as you get into code that you're
dealing with the fringe and weigh the tradeoffs accordingly.
RjS
ps - be careful in implementation to not interact with
matching responses with tags to requests without them.
On Tue, 2004-07-27 at 15:19, Derek MacDonald wrote:
> > > We currently create a usage in that case. It could be argued that we
> > > shouldn't, as it breaks the onNewSession/onTerminate symmetry.
> > >
> > > I'm going to add a SessionProgress handler which notifies the user of
> > > DialogSet level session progress events, so we can have ringing for
> > > non-dialog establishing 180s.
> > >
> >
> > Under what circumstances does a 1xx not establish a dialog? Do you mean
> > the
> > 100?
>
> I also was thinking of 18x's w/out a contact(or a to tag for 3261). Is this
> correct Robert, or is there always an early dialog from a 18x?
>
> >
> > > //called when a 100 or non-dialog-establishing 18x is received
> > > for a request
> > > virtual void onSessionSetProgress(AppDialogSetHandle, const
> > > SipMessage&msg)=0;
> > >
> > > Instead of creating a usage to deliver the 6xx we could add another
> > method
> > > to the SessionProgressHandler.
> > >
> > > //call when a request fails w/out a dialog being established
> > > virtual void onSessionSetupFailure(AppDialogSetHandle, const
> > > SipMessage&msg)=0;
> > >
> > >
> > > I'm okay with this or the Usage creation approach. Get your votes in
> > soon
> > > to break the deadlock.
> >
> > Currently, there is no requirement for the app writer to use the
> > AppDialogSet at all. If we add this in, it will be mandatory for
> > applications to implement it. Still could be the right way to go.
> >
>
> A default implementation of AppDialogSet is provided, but any user who wants
> to track what happens to a particular request will implement an
> AppDialogSet, if only as an asynchronous completion token.
>
> >
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>