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

[Paul Kyzivat <[e-mail]>]

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

[e-mail] wrote:
> 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 


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