[reSIProcate] Re: overlapping NIT in INVITE usage
The SIP WG flipflopped on this so many times I lost track.
Right now, it allows overlapping NI.
Some methods (MESSAGE in particular) disallow overlapping requests with
that method.
I would prefer that DUM not issue overlapping NI. It needs to deal with
other people that send them though.
Here's the relevant spec text for reference:
Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another INVITE transaction is in progress in either
direction.
1. If there is an ongoing INVITE client transaction, the TU MUST
wait until the transaction reaches the completed or terminated
state before initiating the new INVITE.
2. If there is an ongoing INVITE server transaction, the TU MUST
wait until the transaction reaches the confirmed or terminated
state before initiating the new INVITE.
However, a UA MAY initiate a regular transaction while an INVITE
transaction is in progress. A UA MAY also initiate an INVITE
transaction while a regular transaction is in progress.
More inline.
On Nov 18, 2004, at 9:09 AM, Jason Fischl wrote:
Hi folks,
As I work on the rewrite of the InviteSession some questions about
overlapping transactions come up.
In the current implementation, it explicitly disallows overlapping
INFO requests? The first INFO needs to finish before dum allows
another one. It throws if you try to send an INFO while one is
pending. Is this necessary? This behavior is not currently applied to
REFER. What about BYE?
Consider the case where we have an established InviteSession
(Connected). We receive a reINVITE from the peer. What happens if the
peer sends us a second reINVITE before we respond? What happens if the
peer sends us an INFO overlapping with the reINVITE? I'm assuming that
the INFO overlapping the reINVITE is ok and the reINVITE overlapping
the reINVITE is NOT ok and should be rejected with 4xx?
As above, NI can overlap I.
If somebody sends us overlapping INVITEs, they've violated spec, and we
don't
have a chance of figuring out what they really wanted to do. I propose
we send
a BYE.
Jason