Nataraju, My question was exactly about the very first INVITE to which the 2xx response would create a dialog. Now the dialog is in the early state (assuming 101-199 was received) and 422 terminates it. Therefore I was thinking that it is perfectly valid to re-send the INVITE with a new dialog ID.
thanks, Paulius >-----Original Message----- >From: ext Nataraju A B [mailto:[EMAIL PROTECTED] >Sent: 15 January, 2006 09:01 >To: Meskauskas Paulius (Nokia-TP-MSW/Helsinki); >[email protected] >Subject: RE: [Sip-implementors] RFC4028 and 422 response to INVITE > >Sorry, I was misunderstood the question. My earlier answer >would be valid if the 422 response was received for the >initial dialog creating request itself... > >Thanks & Regards, >Nataraju A.B. > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >Nataraju A B >Sent: Friday, January 13, 2006 6:07 PM >To: [EMAIL PROTECTED]; [email protected] >Subject: Re: [Sip-implementors] RFC4028 and 422 response to INVITE > >Comments inline.... > >Thanks & Regards, >Nataraju A.B. >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >[EMAIL PROTECTED] >Sent: Friday, January 13, 2006 3:45 PM >To: [email protected] >Subject: [Sip-implementors] RFC4028 and 422 response to INVITE > >Hello, > >Chapter 7.3 says: > >7.3. Processing a 422 Response > > If the response to a session refresh request is a 422 (Session > Interval Too Small) response message, then the UAC MAY retry the > request. The procedures for retrying are described in Section 7.4. > This new request constitutes a new transaction and SHOULD have the > same value as the Call-ID, To, and From of the previous request, but > the CSeq should contain a new sequence number that is one >higher than > the previous. > > >I was wondering why the new request should contain the same >Call-ID, To and >>From i.e. what will actually happen if the new request will contain >newly >generated Call-ID, To and From? > >[ABN] one simple reason would be to handle similar to how it >would have been handled in case of 401/407 challenge for INV, >REG or any other requests. > >This lead to issue why we have this constraint for retry on failure ? > > In my personal opinion it's been done because the second request >was sent due to failure of first request, hence the same call-id, >from and TO headers have been retained. > >[/ABN] > >thanks, >Paulius > >_______________________________________________ >Sip-implementors mailing list >[email protected] >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >_______________________________________________ >Sip-implementors mailing list >[email protected] >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
