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 > >> > >> [EMAIL PROTECTED] 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 > >>> [EMAIL PROTECTED] for questions on current sip Use > >>> [EMAIL PROTECTED] 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 > >> [EMAIL PROTECTED] for questions on current sip Use > >> [EMAIL PROTECTED] 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 > > [EMAIL PROTECTED] for questions on current sip Use > > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
