[Moving this discussion to sipx-dev.] On Tue, 2009-08-11 at 09:06 -0400, Beeton, Carolyn (CAR:9D60) wrote: > > -----Original Message----- > > From: Worley, Dale (BL60:9D30) > > Sent: Monday, August 10, 2009 4:47 PM > > To: Beeton, Carolyn (CAR:9D60) > > Subject: SipSubscribeClient::addSubscription > > > > I'm thinking of modifying SipSubscribeClient::addSubscription > > so that it > > (effectively) always returns TRUE, and that any failures are reported > > *only* through the use of the callback function. This is to > > simplify the structure of the code, so that there is only one > > place the user of > > addSubscription() needs to handle failure situations. > > > > Do you think this would cause any problems with SAA? > > > > Dale > > > > No, SAA uses this in exactly the same way as the RLS does and would > handle failures the same way. > Will the mSubscriptionEarlyDialogHandle (a return variable) be set in > all cases? or just for success?
Since the effect of the change would be to pretend that the initial send always succeeded, then addSubscription will always set earlyDialogHandle. But that points out a complication: If addSubscription can re-establish subscriptions, it will be sending multiple initial SUBSCRIBEs over time, and those must have different call-ids. The result will be that no single early dialog handle (that is, call-id and from-tag) will describe all of the established subscriptions. If the application uses the subscriptionStateCallback (opaque datum for the callback function) to identify which subscription is due to which call of addSubscription, that will work. But the earlyDialogHandle will become unreliable. But as you say, SAA is like the RLS in that respect, so I will look at how the RLS handles that. Dale _______________________________________________ sipx-dev mailing list sipx-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
