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

List:       sip-implementors
Subject:    Re: [Sip-implementors] Proxy behavior for SUBSCRIBE request
From:       Dale.Worley () comcast ! net
Date:       2007-10-31 21:10:26
Message-ID: 200710312110.l9VLAQUZ022660 () dragon ! ariadne ! com
[Download RAW message or body]

   From: "Pandurangan R S" <pandurangan.r.s@gmail.com>

   My proxy acts as Registrar (RFC 3261) for proxy.com. It also acts as a
   Notifier for reg-event package (RFC 3680).

   Let us consider that user1@proxy.com and user2@proxy.com are registered. Now
   user2 sends a SUBSCRIBE for package "xyz" for the resource
   user1@proxy.com.<user1@proxy.com>(as per RFC 3265, Request-URI should
   be the resource to which the user wants
   to SUBSCRIBE to)
   Then the SUBSCRIBE request will be

   SUBCRIBE user1@proxy.com <user2@proxy.com>
   From: user2@proxy.com <user1@proxy.com>
   Event:xyz
   ....

First, the request will have to be something like:

SUBCRIBE user1@proxy.com SIP/2.0
From: "user2@proxy.com" <user2@proxy.com>
Event:xyz

in order to make sense and conform to SIP syntax.

   How will the proxy identify whether the SUBSCRIBE
      a) needs to be routed based on the contact of user2? (stored at proxy,
   when user2 sent the REGISTER message) OR
      b) needs to act as notifier for this SUBSCRIBE? OR
      c) needs to route towards some other endpoint (say an AS) which can act
   as notifier for this SUBSCRIBE?

If the destination domain (proxy.com) is not one the proxy is
responsible for, it must route the request using the standard SIP
rules (RFC 3263).

If the proxy is responsible for proxy.com, then the proxy must
understand what actual UAs are the notifiers for the event, and what
their addresses are.  The proxy may need to examine the user-part of
the request-URI and the Event header to determine this.  For some
events, like "reg", it will want to route the request to the registrar
for the domain (which may be the proxy itself, acting as a UAS rather
than a proxy).  For other events, like "dialog", it will probably want
to fork the request to all registered contacts, much like it would
handle an INVITE.

Dale

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