Subject: [Sip] Interesting problem with PRACK and resent INVITEs

From: [email-masked]
Date: Thu, 17 Jan 2008 15:23:27 -0500

I was looking at a problem were were having with a phone and
discovered the following interesting situation with PRACK and INVITEs
that have to be resent with authentication.

Consider an INVITE that gets serially forked to two destinations, the
first one doesn't answer and the second one demands authentication:

    UAC             Proxy           UAS 1           UAS 2

     |                |               |               |
F1   | INVITE CSeq 1  |               |               |
     |--------------->|               |               |
F2   |                | INVITE CSeq 1 |               |
     |                |-------------->|               |
F3   |                | 180 CSeq 1    |               |
     |                | to-tag abc    |               |
     |                |<--------------|               |
F4   | 180 CSeq 1     |               |               |
     | to-tag abc     |               |               |
     |<---------------|               |               |
F5   | PRACK CSeq 2   |               |               |
     | to-tag abc     |               |               |
     |------------------------------->|               |
F6   |                | 200 CSeq 2    |               |
     |                | to-tag abc    |               |
     |<-------------------------------|               |
     |                |               |               |
    ---------------------- delay ------------------------
     |                |               |               |
F7   |                | CANCEL CSq 1  |               |
     |                |-------------->|               |
F8   |                | 200 CANCEL    |               |
     |                |<--------------|               |
F9   |                | 487 CSeq 1    |               |
     |                | to-tag abc    |               |
     |                |<--------------|               |
F10  |                | INVITE CSeq 1 |               |
     |                |------------------------------>|
F11  |                |               | 407 CSeq 1    |
     |                |               | to-tag def    |
     |                |<------------------------------|
F12  | 407 CSeq 1     |               |               |
     | to-tag def     |               |               |
     |<---------------|               |               |
F13  | INVITE CSeq 2  |               |               |
     |--------------->|               |               |
F14  |                | INVITE CSeq 2 |               |
     |                |-------------->|               |
F15  |                | 500 CSeq 2    |               |
     |                | to-tag pqr    |               |
     |                |<--------------|               |
F16  | 500 CSeq 2     |               |               |
     | to-tag pqr     |               |               |
     |<---------------|               |               |
     |                |               |               |

Since the PRACK F5 is sent within a forked dialog, we don't think of
it as using up CSeq number space in the space of out-of-dialog
requests.  So when it comes time to re-send the INVITE F13, it's easy
to think that you can just use a CSeq one higher than the original
INVITE F1.  But transaction processing at UAS 1 is likely to notice
that it's already seen CSeq 2 with that Call-Id.  It looks like one
must make sure that the re-sent INVITE has a CSeq higher than has been
used in any derived dialog of the original INVITE.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 17 Jan 2008 16:06:22 -0500

Couple of questions.

Since dialog is a combination of Call-Id + tags, and since F14 does not
have a to-tag, how does UAS correlate this request to the earlier
dialog.

After getting 500 from UAS1, why is not sending the request to UAS2 and
instead sends 500 upstream.

Sanjay

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: Thursday, January 17, 2008 3:23 PM
>To: [email-masked]
>Subject: [Sip] Interesting problem with PRACK and resent INVITEs
>
>discovered the following interesting situation with PRACK and 
>INVITEs that have to be resent with authentication.
>
>Consider an INVITE that gets serially forked to two 
>destinations, the first one doesn't answer and the second one 
>demands authentication:
>
>    UAC             Proxy           UAS 1           UAS 2
>
>     |                |               |               |
>F1   | INVITE CSeq 1  |               |               |
>     |--------------->|               |               |
>F2   |                | INVITE CSeq 1 |               |
>     |                |-------------->|               |
>F3   |                | 180 CSeq 1    |               |
>     |                | to-tag abc    |               |
>     |                |<--------------|               |
>F4   | 180 CSeq 1     |               |               |
>     | to-tag abc     |               |               |
>     |<---------------|               |               |
>F5   | PRACK CSeq 2   |               |               |
>     | to-tag abc     |               |               |
>Since the PRACK F5 is sent within a forked dialog, we don't 
>think of it as using up CSeq number space in the space of 
>out-of-dialog requests.  So when it comes time to re-send the 
>INVITE F13, it's easy to think that you can just use a CSeq 
>one higher than the original INVITE F1.  But transaction 
>processing at UAS 1 is likely to notice that it's already seen 
>CSeq 2 with that Call-Id.  It looks like one must make sure 
>that the re-sent INVITE has a CSeq higher than has been used 
>in any derived dialog of the original INVITE.
>
>Dale
>
>
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: "Theo Zourzouvillys" <[email-masked]>
Date: Thu, 17 Jan 2008 22:33:16 +0000

> must make sure that the re-sent INVITE has a CSeq higher than has been

Dale,

Surely there is no dialog for the INVITE in F14 to be interpreted in
between UAC and UAS1 when it arrives as UAS1, as the previous 487 (F9)
would have terminated the dialog?

 ~ Theo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jan 2008 20:20:25 -0500

Interesting. But I'm not certain I buy it. CSeqs only make sense within 
a dialog. F13 doesn't contain the To-tag abc, so it ought not be 
expected to use a valid CSeq for that dialog.

A different issue here is that that F13 ought not go to UAS1 at all. But 
we treat it as a new transaction, and don't expect the proxy to maintain 
any history across transactions, so we don't have a way to prevent that.

There ought to be something in F11 that causes the request to go only to 
  (in this case) UA2. (In general to whichever node generated the 
challenge, which might have been a proxy rather than a UA.)

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 18 Jan 2008 06:17:39 +0100

Hi, 

>Interesting. But I'm not certain I buy it. CSeqs only make 
>sense within a dialog. F13 doesn't contain the To-tag abc, so 
>it ought not be expected to use a valid CSeq for that dialog.

Correct.

And, the INVITEs shall contain different From-tag values (and Call-ID
values), so UAS 2 will be able to differentiate the dialogs based on
those parameters.

Regards,

Christer

> 
>A different issue here is that that F13 ought not go to UAS1 
>at all. But we treat it as a new transaction, and don't 
>expect the proxy to maintain any history across transactions, 
>so we don't have a way to prevent that.
> 
>There ought to be something in F11 that causes the request to 
>go only to (in this case) UA2. (In general to whichever node generated 
>the challenge, which might have been a proxy rather than a UA.)
> 
> 	Paul
> 
> destinations, the 
> think of 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 
>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Fri, 18 Jan 2008 08:25:50 +0100

Christer,

No, see RFC3261 8.1.1.4:

Note that when requests are retried after certain failure responses that solicit an amendment to a request (for
   example, a challenge for authentication), these retried requests are
   not considered new requests, and therefore do not need new Call-ID
   header fields; see Section 8.1.3.5.

Mid-dialog challenges should use the same from-tag + Call-ID, so although it seems allowed to start anew, IMHO it is better to keep them the same. 
The text could be more clear though (and should have some normative words).

Regarding from tags there is no explicit text, but 22.2 says:

When a UAC resubmits a request with its credentials after receiving a
   401 (Unauthorized) or 407 (Proxy Authentication Required) response,
   it MUST increment the CSeq header field value as it would normally
   when sending an updated request.

This hints at treating the challenge response as a mid-call request (although it may have no to-tag in case of an initial INVITE)

Regarding Dale's case below, this can only occur if UAS1 has a broken SIP implementation (F1, F5 and F13 are 3 independent transactions)

Regards,
Jeroen

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 18 Jan 2008 08:36:50 +0100

Hi, 

>No, see RFC3261 8.1.1.4:
> 
>Note that when requests are retried after certain failure 
>responses that solicit an amendment to a request (for
>example, a challenge for authentication), these retried 
>requests are not considered new requests, and therefore do not need new
Call-ID

Correct.

>Mid-dialog challenges should use the same from-tag + Call-ID, 
>so although it seems allowed to start anew, IMHO it is better 
>to keep them the same. 

So, I guess that means that the second INVITE in Dale's example should
have Cseq => 3.
 
>This hints at treating the challenge response as a mid-call 
>request (although it may have no to-tag in case of an initial INVITE)

Personally I think that EVERY new initial INVITE should be update the
Call-ID and/or From-tag, no matter what triggered it.

But, I guess there is a good reason behind the current text...

Regards,

Christer

> Christer Holmberg wrote:
> > Hi,
> >
> >> Interesting. But I'm not certain I buy it. CSeqs only make sense 
> >> within a dialog. F13 doesn't contain the To-tag abc, so it 
> ought not 
> >> be expected to use a valid CSeq for that dialog.
> >
> > Correct.
> >
> >> A different issue here is that that F13 ought not go to 
> UAS1 at all. 
> >> But we treat it as a new transaction, and don't expect the 
> proxy to 
> >> maintain any history across transactions, so we don't have 
> a way to 
> >> prevent that.
> >>
> >> There ought to be something in F11 that causes the request 
> to go only 
> >> to (in this case) UA2. (In general to whichever node generated the

---

From: Jeroen van Bemmel <[email-masked]>
Date: Fri, 18 Jan 2008 09:02:12 +0100

Christer,
>> .

I interpreted this as "MUST increment (relative to the INVITE being 
challenged)". I guess for initial INVITEs the minimal requirement is 
that the CSeq be different, else merged request detection (8.2.2.2) 
could kick in and prevent the call from succeeding. So both 2 or 3 are 
valid, the text is ambiguous

Regards,
Jeroen

---

From: Bob Penfield <[email-masked]>
Date: Fri, 18 Jan 2008 08:33:46 -0500

I believe that a CSeq of 2 is perfectly valid for the second INVITE (resubmitted with credentials). The RFC 3261 is clear that it should have the same Call-ID and from-tag.  The CSeq number space is per dialog. This second INVITE is not part of any dialog, therefore its CSeq should not be compared with any previous dialog.

If a UA does keep CSeq state for a Call-ID it should be independent of the dialog CSeq state, and not updated by in-dialog requests.

cheers,
(-:bob

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]]
Sent: Friday, January 18, 2008 3:02 AM
To: Christer Holmberg
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [Sip] Interesting problem with PRACK and resent INVITEs

Christer,

Regards,
Jeroen