Cseq incremention is assumed as well. The idea is after getting 423 a new transaction is created ( unique branch and cseq are transaction data ) and remaining information remains same :)
Indresh K Singh >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf >>Of ext Singh, Indresh (SNL US) >>Sent: Wednesday, May 09, 2007 11:23 AM >>To: ext Marco Ambu; SIP-implementors mailing list >>Subject: Re: [Sip-implementors] Rules for "retry" request >>construction after4xx >> >>Hi Marco, >> >>After receiving a 423 response with a retry-after header. A New >>registration request should be built and sent after time indicated in >>the retry-after header, with a different branch identifier, but same >>call-id, from and to header as original registration request. >> >>This is same what would be done if a registration gets challenged or >>registration gets rejected because of issue on the UAS like 500 with >>retry-after. >> >>Regards, >> >>Indresh K Singh >>------------------------------------------------------------- >>Sr. Software Engineer >>SIP Media Control and Signaling >>Nokia Siemens Networks >>Boca Raton, FL-33487 >>Ph: 561-923-5085 (o), 561-923-2048 (o) >>------------------------------------------------------------- >> >> >> >>>>-----Original Message----- >>>>From: [EMAIL PROTECTED] >>>>[mailto:[EMAIL PROTECTED] On Behalf >>>>Of ext Marco Ambu >>>>Sent: Wednesday, May 09, 2007 9:15 AM >>>>To: SIP-implementors mailing list >>>>Subject: [Sip-implementors] Rules for "retry" request >>>>construction after 4xx >>>> >>>>Hi, >>>>I don't clearly understand what to do if a UAC receives a 423 >>>>response >>>>for a REGISTER request. >>>>The new register after 423 is a "retry" [3261 - 10.2.8] >>(after expire >>>>time is modified properly), but what rules shoud be applied >>>>to contruct >>>>the new "retry" request? >>>>1) Call-ID, To and From must be the same and CSeq updated >>or [3261 - >>>>8.1.3.5] >>>>2) new request with different Call-ID, ..., unrelated to the >>>>preceeding >>>>request >>>> >>>>from RFC 3261 >>>>******** >>>>8.1.3.5 Processing 4xx Responses >>>> [401, 407, 413, 415, 416 and 420] >>>> In all of the above cases, the request is retried by >>creating a new >>>> request with the appropriate modifications. This new request >>>> constitutes a new transaction and SHOULD have the same >>value of 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. >>>> >>>> With other 4xx responses, including those yet to be >>>>defined, a retry >>>> may or may not be possible depending on the method and the >>>>use case. >>>> >>>> >>>>10.2.8 Error Responses >>>> If a UA receives a 423 (Interval Too Brief) response, it >>MAY retry >>>> the registration after making the expiration interval of >>>>all contact >>>> addresses in the REGISTER request equal to or greater than the >>>> expiration interval within the Min-Expires header field >>of the 423 >>>> (Interval Too Brief) response. >>>>******** >>>> >>>>Thanks >>>>-- >>>> >>>>Marco Ambu >>>>R&D Software Engineering >>>>Abbeynet S.p.A. - www.abbeynet.com <http://www.abbeynet.com> >>>> >>>>phone: +39 070 2339331 >>>> >>>><http://www.marco-ambu.sitofono.it> >>>> >>>> >>>>_______________________________________________ >>>>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
