Below are my concern for the last response on this subject. Forking generally happens at proxy. So are you trying to describe a scenario where a call was originated from an UAC went through a proxy, which forked the request and after forking it is forwarding different error responses upstream ?? Is it allowed. ?
Regards, Indresh K Singh >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf >>Of ext Rupela, Ravi >>Sent: Wednesday, June 06, 2007 10:27 AM >>To: [EMAIL PROTECTED] >>Cc: [email protected] >>Subject: [Sip-implementors] Behaviour on receipt of second non-2xx >> >>Hi shivelx, >> In this case as being Client UA you don't care about the sending >>second ACK to 6xx response , If we do not send an ACK for the 6xx response ( with a different to-tag ). Then the retransmission of 6xx will continue till timeout happens. This is not recommended as it causes more messaging in the network. If you are B2BUA then you have to store >>dialog and transaction parameters of >>All calls hence you can send ACK to 6xx UAS too. FYI the SIP Endpoints >>doesn't care about receiving ACK if it has sent any non-2xx response. Same comment as above. The SIP endpoints do care about receiving ACKs as they have to stop the retransmission timers only after receiving an ACK. Stopping of retransmission is important from network congestion perspective ( because of undesired messages due to retransmission ) >> >>Regards >>Ravi Rupela >> >> >> >>Hi, >> Need some inputs for this scenario in UDP case: >> UAC is sending invite,UAS sends a 4xx for it,UAC sends ACK for it. >> Before the invite client transaction has cleared up , UAC >>receives a >>6xx with a different to-tag for the same invite.(all other parameters >>are same as 4xx). I guess that in general this wont be happening,but >>assume that we receive this second final non-2xx response >>with different >> >>to-tag. >> RFC 3261 says ".... it is possible that it will generate multiple >>responses from different servers. >> These responses will all have the same branch parameter in the >>topmost Via, but vary in the To tag. The >> first response received, based on the rules above, will be >>used, and >>others will be viewed as retransmissions. >> That is not an error;" >> >> RFC 3261 also says that "The ACK request matches a transaction >> if the Request-URI, From tag, Call-ID, CSeq number (not the >>method), >>and top Via header field match >> those of the INVITE request which created the transaction, >>and the To >>tag of the ACK matches the To >> tag of the response sent by the server transaction" >> How should the client transaction behave? >> 1]Should it retransmit the same ack which it sent for the 4xx? >> 2] If client retransmits the same ack,then the to-tag in that ack >>will be that of one received in 4xx.It will be treated as >>stray message. >> 3] How should the invite server transaction handle such ack with >>different to-tag(if the ack of 4xx was retransmitted with old tag)? >> Inputs will be appreciated. >> >> >> >>_______________________________________________ >>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
