Hi Bhagat,
     After the initial INV-200 transaction you
would never receive a request where the URI points
to an A-O-R. This is because one of the foll. will
happen during the INV-200 :
-> One or more proxies will Record-Route. Subsequent
   transactions will arrive with a set of Route headers
   and you will forward it to the next hop based on the
   Routing procedures.
-> None of the proxies Record-Route. In that case the remote
   URI (Contact present in INV/200) will be present in
   the Request-URI. This again will be a FQDN/IP address
   for which you need not run a location service lookup.

So what you describe is an error condition. You need not
examine the To tag to determine forking behaviour. Being
transaction stateful, you should be agnostic to such info
and simply fork the request in these cases.

Regards,
Subhash.
Hughes Software Systems
http://www.hssworld.com





"Janarthanan, Bhagatram" <[EMAIL PROTECTED]> on 10/25/2002
12:29:06 PM

To:   [EMAIL PROTECTED]
cc:    (bcc: Subhash Ullal Nayak/HSSBLR)

Subject:  [Sip-implementors] transaction-stateful proxies




Hi,

   I am confused about how a transaction stateful proxy should decide on
forking requests. According to the draft, a transaction stateful proxy will
not hold states through the entire call. Rather it will only remember
things
for the duration of the transaction and will treat each transaction as a
new
context.

However Rfc-3261 also states
  "Unlike an INVITE, which can fork, a re-INVITE will never fork, and
therefore, only ever generate a single final response. The reason a
re-INVITE will never fork is that the Request-URI identifies the target as
the UA instance it established the dialog with, rather than identifying an
address-of-record for the user".

  I would like to know, how are we supposed to treat a request, which
arrives at a transaction stateful proxy with only an address of record of
the user and contains a "to-tag" (indicating that it is part of an existing
call/session).
 To be specific, What should be done, if we receive the following requests
in a transaction stateful proxy ?

              INVITE     with "To-tag" and only "address-of-record for the
user"(not-resolved)
              BYE        with "To-tag" and only "address-of-record for the
user"(not-resolved)
              ACK        with "To-tag" and only "address-of-record for the
user"(not-resolved)

Should we reject all such requests or Should we treat them as new request
and fork them ?

Thanks,
Bhagat
_______________________________________________
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

Reply via email to