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
