[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    [Sip-implementors] Proxy Processing Doubts
From:       "Sp.Raja" <spraja () isofttechindia ! com>
Date:       2002-08-30 4:01:16
Message-ID: NGBBILMLCDGBFDCMMBEPIENKCAAA.spraja () isofttechindia ! com
[Download RAW message or body]

Hi all,

************************************************************************
RFC 3261 Sec 16.5 item 7 reads
         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)


************************************************************************
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?
Ex.

UAC            Proxy1     Proxy2
--------->    -------->   -------->------------------> to 192.168.0.1,
192.168.0.2 [pc1 resolved to 2 IPs]
INVITE a@b.com            INVITE pc1@b.com
                          -------->------------------> to 192.168.0.3,
192.168.0.4  [pc3 resolved to 2 IPs]
                          INVITE pc3@b.com

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


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic