----- Original Message ----- From: "Sp.Raja" <[EMAIL PROTECTED]> To: "Sip-Implementors" <[EMAIL PROTECTED]> Sent: Thursday, August 29, 2002 11:49 PM Subject: [Sip-implementors] Proxy Processing Doubts
> Hi all, > > ************************************************************************ > RFC 3261 Sec 16.5 item 7 reads It is actually sec 16.6 > Since each attempt uses a new client transaction, it represents > a new branch. Thus, the branch parameter provided with the Via > header field inserted in step 8 MUST be different for each > attempt. > ************************************************************************ > Why should we change branch parameter for each try in the set of tuples > resulted during DNS resolution? even though it might be a new client > transaction, the message is not seen by any one (it was a network error, and > the message was not delivered to any one) According to RFC 3263 section 4.3, you would "try" the next tuple when you received a 503 response (which is not a network error), or a timeout. Creating a new branch ID ensures there are not any duplicate requests out there. A new branch ID needs to be created for each new client transaction. Why would you special case a transport error? > > > ************************************************************************ > Same section > If the client transaction reports failure to send the request > or a timeout from its state machine, the proxy continues to the > next address in that ordered set. If the ordered set is > exhausted, the request cannot be forwarded to this element in > the target set. The proxy does not need to place anything in > the response context, but otherwise acts as if this element of > the target set returned a 408 (Request Timeout) final response. > ************************************************************************ > Does it mean for each forked branch there is no more level of serial > forking? Here it is talking about an ordered set of destinations for a specific logical target (a single target URI). There may be additional logical targets (URIs) that you can fork to serially or in parallel. 16.6 is talking about how to forward each target in the target set created in section 16.5. > Ex. > > UAC Proxy1 Proxy2 > ---------> --------> -------->------------------> to 192.168.0.1, > 192.168.0.2 [pc1 resolved to 2 IPs] > INVITE [EMAIL PROTECTED] INVITE [EMAIL PROTECTED] > -------->------------------> to 192.168.0.3, > 192.168.0.4 [pc3 resolved to 2 IPs] > INVITE [EMAIL PROTECTED] > > Sec 16.4 reads > The proxy MUST inspect the Request-URI of the request. If the > Request-URI of the request contains a value this proxy previously > placed into a Record-Route header field (see Section 16.6 item 4), > the proxy MUST replace the Request-URI in the request with the last > value from the Route header field, and remove that value from the > Route header field. The proxy MUST then proceed as if it received > this modified request. > > What if Route header is not present in the above case, should it be > considered as a request to a proxy ?? > > Same section > If the Request-URI contains a maddr parameter, the proxy MUST check > to see if its value is in the set of addresses or domains the proxy > is configured to be responsible for. If the Request-URI has a maddr > parameter with a value the proxy is responsible for, and the request > was received using the port and transport indicated (explicitly or by > default) in the Request-URI, the proxy MUST strip the maddr and any > non-default port or transport parameter and continue processing as if > those values had not been present in the request. > A request may arrive with a maddr matching the proxy, but on a > port or transport different from that indicated in the URI. Such > a request needs to be forwarded to the proxy using the indicated > port and transport. > > This is quite confusing, can some one explain what does it really mean ? > > > Thanks for your answers > -Sp.Raja > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
