David Stuart wrote:
Hi All,
I have some questions about the message flow with respect to SUBSCRIBE and NOTIFY when there is a proxy/registrar involved. Maybe someone could clear it up for me. In particular, I need to know how the proxy/registrar should deal with subscribe and notify, assuming it is functioning in the PA role. I have 3 scenarios in mind, maybe someone could tell me which is the right one:
Actually, I don't think any of them are consistent with unwritten best current practice. Some may also be wrong, depending on interpretation. More comments below.
(time to turn on the fixed-width font)
The first example, I am assuming that the registrar fully functions as a PA and does not forward requests to the peer UA (UA2 in this diagram). It is assumed that UA1 is SUBSCRIBEing to UA2:
+------------+ +--------------+ +-------------+
| | | proxy/ | | |
| UA1 | | registrar | | UA2 |
+-----+------+ +-------+------+ +------+------+
| | | | SUBSCRIBE | | +-------------------------> | | OK | | <-------------------------+ | | NOTIFY | | <-------------------------+ | | OK | | +-------------------------> | | | REGISTER | | <------------------------+ | | OK | | +------------------------> | NOTIFY | | <-------------------------+ | | OK | | +-------------------------> |
This could be considered valid, but IMHO isn't a mainstream approach.
The proxy/registrar/pa isn't technically doing anything wrong. But presumably it is getting all of its information from the register message. This may be sufficient for open/closed, but its not clear how it would get any more presence information.
You could couple this with UA2 sending PUBLISH messages to its own AOR, which would be handled by the PA function of the server. Then it would make more sense.
The second example, the proxy/registrar functions more like a proxy and less like a PA in that it simply forwards the request to the peer UA2:
+-----------+ +--------------+ +--------------+ | | | proxy/ | | | | UA1 | | registrar | | UA2 | +-----+-----+ +-------+------+ +-------+------+ | SUBSCRIBE | | +----------------------> | | PENDING | | <----------------------| SUBSCRIBE | | -------------------------> | | OK | | OK <------------------------+ <----------------------| | | | | | | | | NOTIFY | <-----------------------------------------------+ | OK | +-----------------------------------------------> | | |
I'm not sure about this because I don't know what you intend by the line marked PENDING. If you mean this to be a 100 response, then this could be ok.
But PENDING is also a form of notification, so maybe you meant a NOTIFY containing PENDING status. If so, for the proxy/pa to respond with pending it must accept the subscription and then send a NOTIFY. At that point it makes no sense for it to send a SUBSCRIBE onward as a proxy.
Finally, the third is basically a mixture of the first two.. probably wrong but this is closer to some behavior I've seen before, where the proxy/registrar both responds to the SUBSCRIBE request and forwards it to the peer UA:
+------------+ +--------------+ +---------------+
| | | proxy/ | | |
| UA1 | | registrar | | UA2 |
+-----+------+ +-------+------+ +-------+-------+
| SUBSCRIBE | | +----------------------> | | PENDING | | <----------------------+ SUBSCRIBE | | ----------------------> | | OK | | OK <---------------------+ <----------------------+ | | NOTIFY | | <----------------------+ | | OK | | +----------------------> | | NOTIFY | <--------------------------------------------+ | OK | +--------------------------------------------> | | | | | |
Same comments as above apply here regarding pending. Assuming your PENDING means 1xx, this is at best shady, and likely wrong. I think the only way to make this seem valid is to treat it as a forking case, where the proxy/registrar/pa, acting as a proxy, forks the request to itself, acting as a PA, and to UA2. Then, even though its own PA accepts the request it doesn't cancel the fork to UA2. You end up with two dialogs, but only one OK is sent back to UA1. Can't tell from picture, but lets assume the OK to UA1 is the one originated by the proxy/pa acting as a PA. That establishes one dialog. The subsequent NOTIFYs from it are within that dialog. The first NOTIFY from UA2 to UA1 then establishes another dialog, and all subsequent NOTIFYs from it use that one.
This isn't a good situation. The presence event package says that subscriptions aren't supposed to be forked. UA1 doesn't know what to do with notifications from different sources.
If someone could please let me know which of these is closest to the truth, it would go a long way for me. Also I may have made mistakes above so feel free to correct me.. :)
As noted above, your first flow could be improved by having UA2 PUBLISH its presence.
If you want the proxy to serve as a standin UA when UA2 isn't registered, you can make something somewhat similar in spirit to your last flow that achieves that.
The proxy can accept the subscription if UA2 isn't registered, and it can NOTIFY with a status of PENDING if that is what it wishes to do.
When UA2 registers, the subscription can be migrated. This is done by prematurely expiring the current one, sending a final NOTIFY. UA1 will then realize it needs to subscribe again. When it does so, the proxy/registrar/pa will decide to act as proxy and proxy the request to UA2. It will then accept it and begin sending NOTIFYs. This is explained in 3265.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
