Either one will work since each Subscribe request will have it's
associated identifiers to distinguish. But from a user perspective, I
think option 1 makes more sense
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David
Viamonte
Sent: Tuesday, January 30, 2007 8:51 AM
To: [email protected]
Subject: [Sip-implementors] Sending N SUBSCRIBE messages
Hello,
I come back with a question regarding an "implementation
issue"... I think.
The case is as follows: an application wishes to subscribe to
the Presence of N Presentities (no RLS is used). So N SUBSCRIBE messages
are sent.
Each SUBSCRIBE message is independent of the others, so N SIP
dialogs are created.
I see two options here:
1. The client sends N SUBSCRIBE requests (each one requesting
Presence info about a different Presentity) independently and
asynchronously. Answers and NOTIFY requests are processed independently.
2. For each Presentity it wishes to subscribe to, the client:
a) Sends the SUBSCRIBE request
b) Waits for the 200 OK answer
c) Waits for the NOTIFY request
d) Sends a 200 OK answer
The next SUBSCRIBE request is not sent until step 2.d above is
completed (or 2.b, in case of a 4xx response to the SUBSCRIBE request).
Which one do you see as more logical or convenient? Is there
anything fundamentally wrong in any of the two options? I think option 1
is perfectly valid (?). Option 2 may be a bit less agressive in terms of
generating peaks of incoming requests.
Thanks,
David
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
