[reSIProcate] Re: overlapping NIT in INVITE usage

Robert Sparks rjsparks at nostrum.com
Thu Nov 18 16:48:58 CST 2004


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




More information about the resiprocate-devel mailing list