Not exactly. The request sent to and the response from each fork will have a separate branch. Consequently, the transaction layer will treat each as a separate transaction. Thus, each transaction is handled independently of the other transactions from the other forks. So as far as responses and timeouts etc goes you only consider one transaction at the time.
You do not have to look at the to-tag at all. Just look at the branch and keep each transaction as an independent unit in the transaction layer. Thus, even if you get a provisional response from one fork you should still keep sending retransmits of the request to other forks until you get some response from them or it times out. Hope this explains. Alf On Wed, 2006-09-27 at 15:38 +0200, Markus Hofmann wrote: > Hi nandakishore, > > in SIP you have the possibility of forking INVITEs. This means that you > can get provisional responses from different UAS. The only possibility > to detect this is the To tag. But the transaction layer is not > responsible to detect forking INVITEs. This part is done by the UA core > (early dialog). > > In my understanding is provisional responses and successful responses > for INVITE requests end-to-end messages and are handled by th UA core. > All other responses are hop-to-hop messages which are handled by the > transaction layer. > > I hope this helps. > > Regards, > Markus > > > > nandakishore wrote: > > Hi all, > > > > I am having some ambiguity regarding the handling of prov response > > retransmissions received by UAC. > > > > Consider the scenario where UAC receives a provisional response-then it > > passes the message to the TU and moves from "Calling" state to the > > "Proceeding" state. > > > > Now if it receives retransmission(s) of the provisional response, should the > > retransmission(s) be passed to the TU or should they be filtered out? > > > > Also should the timer be reset each time the retransmission is received? > > > > > > > > I found the following entry in the RFC regarding this -- > > > > If the client transaction receives a provisional response while in > > > > the "Calling" state, it transitions to the "Proceeding" state. In the > > > > "Proceeding" state, the client transaction SHOULD NOT retransmit the > > > > request any longer. Furthermore, the provisional response MUST be > > > > passed to the TU. Any further provisional responses MUST be passed > > > > up to the TU while in the "Proceeding" state. > > > > > > > > However in another section of the RFC, I found this somewhat contradictory > > statement-- > > > > The client transaction is also responsible for receiving responses > > > > and delivering them to the TU, filtering out any response > > > > retransmissions or disallowed responses (such as a response to ACK). > > > > > > > > -nanda kishore > > > > > > > > > > > > This e-mail and attachments contain confidential information from HUAWEI, > > which is intended only for the person or entity whose address is listed > > above. Any use of the information contained herein in any way (including, > > but not limited to, total or partial disclosure, reproduction, or > > dissemination) by persons other than the intended recipient's) is > > prohibited. If you receive this e-mail in error, please notify the sender by > > phone or email immediately and delete 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
