On Tue, 2009-03-03 at 13:51 +0000, Hutton, Andrew wrote: > However this did prompt me to have a look at section 6 of -03 > (Examples). This shows that the caller UA generates two SUBSCRIBE's > using the same Call-Id and the text below the diagram states: > > "The caller's agent adds to these URIs an 'm' parameter (if possible). > In this case, the caller's agent forks the SUBSCRIBE to two > destinations, with appropriate Request-Disposition." > > This I think is a bit strange as I don't think that many UA SIP Stack > implementations provide a service to "fork" in this way. Therefore I > think we may need a different mechanism to allow the callee to determine > that the two subscribes are related.
The stack I am most familiar with (sipX) can be used to implement proxies, so it has no trouble issuing two requests with the same Call-Id. But that may not be true of other stacks, particularly those intended exclusively for use in UAs. The tremendous advantage of using the same Call-Id in both SUBSCRIBEs is that the existing "merged request" logic will identify duplicates. Other than for efficiency, I don't think that it is necessary to detect duplicate subscriptions arriving at a callee -- if duplication is not detected, the caller has two entries in the callee's queue. The worst result from that is that the caller is not available when the first entry is selected, and then the second entry is selected, causing the caller to be rung again. Dale _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
