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

["Sanjay Sinha (sanjsinh)" <[e-mail]>]

 
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: [e-mail] [mailto:[e-mail]] 
>Sent: Thursday, January 17, 2008 3:23 PM
>To: [e-mail]
>Subject: [Sip] Interesting problem with PRACK and resent INVITEs
>
>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