RE: [reSIProcate] DUM: Enqueue conference call results

["Derek MacDonald" <derek@xxxxxxxx>]

I've been working on this and there are some interesting API questions
surrounding #3.

Currently we do not call InviteSessionHandler::onConnected(for UAS) until
the ACK is received.  This is fine in low-latency networks.

However, after testing w/ FWD(pathological, I know) a few issues arise.

Proposals:

Normal Media(answer in 200 or before):

UAC: Call onConnected when the 2xx is received, RTP is established.  If the
ACK is late this doesn't delay the call.  If the ack doesn't arrive,
13.1.1.4 states that the call should be torn down, but I don't see why a
phone w/ a valid RTP stream would wish to do this. The app decides when it
receives the ackNotReceived callback.

UAS: call onConnected when 2xx is sent?

Late Media:

1.) Don't call onConnected until ACK is received
        +hides late media from user; avoids additional callback
        -ties offer/answer & SIP state machines together
2.) Call onConnected when 2xx is received. Additional callback,
offerAnswerNegotiationFailed is called if the ACK is not received or does
not contain any media.
        -additional callback
        +state machines are not tied together
        

Also, in any case there is an ackNotReceived callback.  The user can choose
to tear down the call at this point(b2bua, maybe) or not(endpoint).

I'm leaning toward option #1 for late media.  Failure of ACK arrival is
fatal for late media.
        - onTerminated is designed to take a failure response; currently
faked out w/ a 408. Could add an overload.
        + easier for the API user


Thoughts?

Derek

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Derek MacDonald
> Sent: Friday, July 23, 2004 5:01 PM
> To: 'Rohan Mahy'
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [reSIProcate] DUM: Enqueue conference call results
> 
> So, here are the changes that I will make next week as a result of the
> enqueue discussion.
> 
> 1.) makeCancel will migrate to DialogSet, CANCEL/provisional responses to
> re-invites will be ignored. Calling end on a dialog will call the
> DialogSet
> level cancel if appropriate.
> 
> 2) Users can start a new Invite transaction even if they are waiting for
> the
> ACK of another invite transaction as a UAS.  Ie -- I can put you on hold
> even though I'm still retransmitting the 200.
> 
> 3.) There will be a new callback to indicate that no ACK was received for
> a
> particular transaction, rather than the dubious overloaded 408.
> 
> 4.) ackConnection will go away. Call setAnswer & send() instead.  If the
> SDP
> state machine does not require an answer, the ACK will be sent immediately
> when the 200 is received.  ACK adornment must be accomplished through
> onReadyToSend.
> 
> send with no parameters is the new enqueue...this will eventually be
> extended to support PRACK/180rel/etc.
> 
> 5.) In Dialog requests that are generic to both subscription & invite
> dialogs will migrate to DialogUsage, all other will be added to
> InviteSession.  Only one in-dialog requests at a time will be
> allowed(exception).  Scott, I'll talk with you about how this should all
> be
> implemented.
> 
> --Derek
> 
> 
> 
> 
> 
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel