[reSIProcate] DUM and ending InviteSessions

[Derek MacDonald]

That sounds right, we have a timer relating to the following snippet of the
rfc, end of 13.3.1.4, which is the only case you can send a BYE w/out
receiving an ACK.

   If the server retransmits the 2xx response for 64*T1 seconds without
   receiving an ACK, the dialog is confirmed, but the session SHOULD be
   terminated.  This is accomplished with a BYE, as described in Section
   15.

So, this would involve changing code in both dispatch methods.  end will
cause a transition to terminated when called in the accepting state, and the
BYE will be send when an ACK is received or the  WaitForAck timer fires.
I'll make this change unless this is horribly wrong.

As for CANCEL, that's right but it deosn't really matter as
ClientInviteSession can never enter the proceeding state as 100's don't have
To tags and the usage is not created from a 100.  This type of CANCEL would
have to be handled at the DialogSet level.  Change DialogUsageManager to
dispatch 100's to DialogSets, make sure you don't create usages from
anything w/out a to tag(this will cause leaks, and graceful shutdown will
hang).  If you recieve a 100, the DialogSet will transition into a
cancellable state. Then calls to DIalogSet::CANCEL will have enough state to
determine if a CANCEL can be sent.

We need to think about how this affects the API.

--Derek


13.3.1.4 The INVITE is Accepted
  -----Original Message-----
  From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org]On Behalf Of Scott
Godin
  Sent: Friday, July 09, 2004 6:25 AM
  To: 'resiprocate-devel at list.sipfoundry.org'
  Subject: [reSIProcate] DUM and ending InviteSessions


  Hi Guys,



  I've noticed something that may need correct in DUM - I just want to make
sure I'm right with these statements before proceeding:

    1.. The ClientInviteSession should not throw an exception if end() is
called in the Proceeding state - it should send a CANCEL.
    2.. The UAS - ServerInviteSession currently will send a BYE (via end())
in the Accepting State - but I'm pretty sure this is not valid - it needs to
wait until it transitions into the Connected state (ie. Receives the ACK)
before it can send the BYE.. Some quotes from RFC3261:


  RFC3261 - 13.2.2 - "If the 2xx contains an offer (based on the

  rules above), the ACK MUST carry an answer in its body. If the offer in
the 2xx response is not acceptable,

  the UAC core MUST generate a valid answer in the ACK and then send a BYE
immediately."



  RFC3261 - 15 - "A UA MUST NOT send a BYE outside of

  a dialog. The caller's UA MAY send a BYE for either confirmed or early
dialogs, and the callee's UA MAY

  send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs.
However, the callee's UA

  MUST NOT send a BYE on a confirmed dialog until it has received an ACK for
its 2xx response or until the

  server transaction times out."



  If I'm right - any thoughts on how to deal with this?





  Scott Godin

  Research and Development

  Computer Talk Technology

  slgodin at icescape.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20040709/a149db09/attachment.htm>