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

["Christer Holmberg" <[e-mail]>]

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
>header fields; see Section 8.1.3.5.

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. 
>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.

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.
> >
> > 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
> >>
> >> [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
> >>
> >
> >
> > _______________________________________________
> > 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