Comments inline... Thanks & Regards, Nataraju A.B. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 15, 2006 8:40 PM To: [EMAIL PROTECTED]; [email protected] Subject: RE: [Sip-implementors] RFC4028 and 422 response to INVITE 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. [ABN] as I mentioned in my earlier mail, the second INVITE being sent is in some way related to initial INVITE. Hence the retaining the call-id might have been selected. If you see any other failure scenarios, there is no new INVITE request sent because of the failure for the initial INVITE request. You can observe the same logic being applied for REG/401/ACK or REG/407/ACK scenarios also.... [/ABN] 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
