A couple of points: 1. A new branch identifier will result from the computation. It will be different because of the new URI that will be used (the branch id computation takes into account URI, From, To, Call-ID, CSeq and a couple of other fields).
2. (on the lines of Bob Penfield's response) A 3xx situation results in a 'recursive' action taken at the proxy (MUST according to the RFC) if the 302 is received by the proxy. The 'To', 'From', 'CallId', and 'CSeq' necessarily need to be the same since the upstream entities (including UAC) will need these to be the same; they will have transactions that need to be processed when a '200 ok' makes it back. The URI in the INVITE that gets sent downstream (in response to the 302) will of course be different (will have to be copied from 'Contact'. 3. The rules are easier if the 302 reaches the UAC (which is probably the case you are interested in). The UAC at this point has no obligation to continue the previous transaction. It is free to change 'To', 'Call-ID', and 'CSeq' since there are no upstream entities after the UAC for which any correlation need be done for transaction processing. Optionally, it may behave like a proxy does. Regards, -Ganesh The text is talking about the Via header the proxy places in the new request, not the Via one from the previous hop. You would have checked the Via for a retransmission before sending the request that resulted in the 302 response. UAC Proxy NH1 NH2 | F1 INVITE | | | |------------>| | | | F2 100 | | | |<------------| F3 INVITE | | | |----------->| | | | F4 302 | | | |<-----------| | | | F5 ACK | | | |----------->| | | | | F6 INVITE | | |------------------------>| The proxy inserts a branch ID in its Via in the invite it sends to the first next-hop (F3). When it gets the 302 response, it sends the invite to the second next-hop (F6). This Via in the new request must get a new branch id so responses to F6 are not confused with responses to F3. Note that the proxy may have forked the invite to multiple next-hops (NH1s) when it first sent it on (F3), and the 302 may have indicated multiple contacts resulting in multiple NH2s at F6. All of these client transactions (one per INVITE sent at F3 and F6) are associated with the server transaction (F1). They have the same From, To, Call-ID, and CSeq. Each of the client transactions must have a unique branch ID in the top Via inserted by the proxy. I hope that helps. cheers, (-:bob __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
