|
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
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:
- The
ClientInviteSession should not throw an exception if end() is called in the
Proceeding state – it should send a CANCEL.
- 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@xxxxxxxxxxxx
|