| Janet,
I'll expand a bit, but I think anything more would probably be best in the form of text+references, and an offline discussion if needed.
land mobile radio, commonly used by police/ambulance/first-responders, has been the poster child for NON-interoperable systems. They operate within Radio Frequency Sub Systems (RFSS) using a common air interface (CAI) and the fixed station interface (FSI) -- using TIA as an example. The inter sub-system interface (ISSI) is used to extend interoperability between RFSSs, and here is where SIP is being incorporated for call control between RFSSs. Initially, the system uses stateful SIP proxies, but later on stateless proxies are expected to be incorporated in the architecture. In addition, there is a desire to incorporate RPH and replace TIA's current approach of overloading the SIP Priority value with TIA-specific values (this is very aggravating, but hopefully reason will win out). Hence, adding RPH to responses would be constructive given the potential for stateless proxies in the sample calling segments below
Calling <------->Calling <-------->Called <------>Called serving home home serving RFSS RFSS RFSS RFSS
with respect to PoC, there are efforts to build bridging architectures that provide interoperability between the ISSI/RFSS and PoC systems using SIP in order to seamlessly extend the push-to-talk feature of the different architectures. Some designs for these bridges advocate stateless SIP proxies that just map calls of one system to the next.
-ken
On Nov 28, 2007, at 5:01 PM, Janet P Gunn wrote:
Ken,
Could you expand on these other use cases, and how they would benefit from RPH in responses?
Thanks
Janet
ken carlberg < carlberg g11.org.uk">carlbergg11.org.uk> wrote on 11/27/2007 11:04:44 AM:
> Janet,
>
> sorry for the tardy comments on the thread. when I read the draft, a
> couple of other use cases outside of the GETS model came to mind that
> would seem to prompt a need for an R-P header in a SIP response. In
> the land mobile radio arena, we have bridging architectures/
> technologies like the ISSI that use SIP as a foundation to bridge
> autonomous subnets of P25 systems. These tend to be resource
> constrained systems of multi-level precedence, and so having a
> corresponding R-P header in SIP responses would fold in nicely with
> what is being built today and planned for the near future.
>
> outside of that, there are also some efforts to bridge ISSI with Push-
> to-talk over Cellular (PoC) with SIP, though this is quite preliminary
> so I don't know if I'd list this as another use case. But in any
> event, I think it would be helpful if you could broaden the problem
> statement in your draft so that it is not strictly focused to just
> GETS. Subsequent to this broader statement, you could then provide a
> more in-depth discussion of the GETS *example*.
>
> also, is it your plan to progress your draft in the SIPPING WG given
> that it deals with a requirement? I see its on the SIP agenda along
> with James' related draft, which is helpful, but I assume that further
> progress would be shifted to SIPPING.
>
> -ken
>
|
