Provide location for call creation process

[stroncoso]

What type of PR is this?

Add one of the following kinds:

• enhancement/feature

What this PR does / why we need it:

Current SIM-less calls can't implicit know the source of the call. SIM is not allocated on the device (RAN location is not possible) and IP location is not trustable (WiFi and other use-cases). Emergency calls call type included a dedicated object to locate the source of the call.

• Emergency call location feature at Add Emergency Calling support (callType + PIDF-LO location) #120

So, this PR leverage that idea to be used for any other use, commercial or residential, along with the emergency use case.

Which issue(s) this PR fixes:

Fixes #79

Special notes for reviewers:

• LocationDetails schema is instantiated as originatorLocationDetails and receiverLocationDetails
  • webrtc-call-handling.yaml just states the originatorLocationDetails as part of the call request
  • webrtc-events.yaml requires differentiating both: originator and receiver

Changelog input

 release-note
- webrtc-call-handling.yaml(feat): uses optional `originatorLocationDetails` as part of the call request
- webrtc-events.yaml:  requires differentiating both: originator and receiver 

Additional documentation

n/a

[deepakjaiswal1]

Thanks for the update. Extending location beyond emergency calling to regular calls is a useful enhancement. That said, the current spec changes leave a few important behaviors unclear and may lead to inconsistent implementations.

1) “originator” vs “receiver” location is not a great fit (especially after call setup)

The fields originatorLocationDetails and receiverLocationDetails may look reasonable at first glance, but they become confusing once the call is established and there is a ongoing need to share location sharing:

• After setup, either party may decide to share or update their location at any time.
• At that stage, “receiver/originator” is not a meaningful distinction for location sharing, and can even become misleading (e.g., the party that didn’t initiate the call may share location later, and labeling it “receiver location” is more confusing than helpful).

In my view, location should be treated as “provided by the party sending this message/update” rather than being expressed as fixed originator/receiver properties (and it shouldn’t require echoing the remote party’s location back under a role-specific field).

2) Specify peer-party (terminating side) location sharing during call setup

Right now the change clearly supports adding location details at session creation (initiating side), but it does not clearly specify how the peer/terminating party shares location during setup for regular calls.

If Party B wants to provide its location as part of accepting the call, it would be best to explicitly define that:

• The answering party MAY include locationDetails as part of the answer/accept step (i.e., when submitting the answer SDP / accepting the session).
• The semantics should be explicit: locationDetails included in the answer/accept describes the answering party’s device.

This keeps the model consistent with offer/answer semantics during setup and avoids the need for originator/receiver naming in setup messages.

3) Specify location sharing after call setup using the existing session status update API (for both regular and emergency calls)

For both regular and emergency calls, the spec should define how location can be shared/updated after the call is established. The CAMARA WebRTC API already has a natural “existing hook” for post-establishment changes:

• PUT /sessions/{mediaSessionId}/status (session status update)

I suggest allowing a locationDetails update via the session status update API with clear rules:

• A party MAY provide/update its location after establishment by sending locationDetails in the session status update request.
• The location in that update applies to the party making the update (simple and unambiguous).

[teikuran]

Sorry for this late comment. As I commented in the last call, can we add following description to LocationDetails?

"Providing this information is specific to certain use cases and does not imply a guarantee of any particular server-side action or behavior."