=
 
 

Problem Statement


Source of the problem :
  • Service/Feature may be implemented/provided
    • Partially on UA
    • Partially on server
    • Fully on UA
    • Fully on server

  • Service/Feature may be implemented/provided
    • Using non-signalling channel (DTMF etc.)
    • Using signalling channel (SIP methods, )
    • Using specific call-flows

  • Service/Feature may have various interpretations.
  • When service/feature is provided by a server, UA might assume one approach when
    the server is providing a service in another.
Illustrating the problem:

Target service/feature : Call park

Call park requires some kind of 'indication' to be emitted by the phone that signals a park request. There are many ways to do this:

1. Assuming PBX is a b2bua, the phone emits a DTMF feature code (rfc2833) on the call; this is captured by the PBX, interpreted as an invocation request, mapped to the park feature. The call is then parked at the PBX, and can be picked up elsewhere. I *think* this is the mechanism Udit is talking about.

2. Similar to 1, except invocation is done via some kind of signaling channel mechanism (INFO, proprietary methods, etc.)

3. Phone is a bit more intelligent, and knows the user wants to invoke Park. So, it REFERs to the park server, having it replace its call with the participant (as described in the service-examples draft)

4. conference mechanism; park is implemented by viewing the park server as a conference bridge. So, the invoking UA creates an ad-hoc conference bridge, transfers the correspondent into it.

and there are more.

Interop failures are anticipated when a UA assumes one mechanism, and the PBX and other phones assume different ones, we have no hope of interop.