Comment at end
Salvatore Loreto wrote:
Hi Paul,
thanks for you answer, as always your comments are food for thoughts.
If 3pcc is an heavy weight mechanism or not could be a long and
controversial issue and different people will have
different opinion on it I am sure,
on the other hand I agree with you that correlation will introduce some
extra weight as well but not
comparable with the one introduced by 3pcc mechanism at least in my
opinion.
It is true that "if the 3pcc mechanism is used, only the device that
wants to exploit another device to extend its call need implement it.
Neither the subordinate device nor the other party need do anything
special."
but is the 3pcc mechanism largely implemented and used in the existing
UA at the present?
which probability we have that at least one device, among the ones used
by an user, will support it?
I agree that "the burden of the correlation falls on UA that has no need
for correlation. This also makes adoption more difficult."
but it will depend from how difficult to implement will be the solution
that will be able to propose.
So here at least we have at least the possibility that if the solution
won't be difficult to support, it will be largely adopt.
Having said that, I'd like to check with you what happen if the UAs are
behind a NAT and they use ICE to check
connectivity and negotiate candidates.
To be more clear on what I mean,
let consider for example one of the use cases described in the current
draft
2.1. Using Two Separate UAs to Start a Conversation
Laura is at her office. On her desk, she has a PC with a soft
client
and a desk phone. The PC has a low-quality built-in microphone and
is connected to high-quality speakers.
Laura wants to establish a voice session with Bob using the desk
phone as the microphone and the soft client as the speaker.
and consider the scenario where all the Alice different UAs are in a
network behind a NAT.
Now if we could use a correlation mechanism, each of the Alice UAs will
perform,
independently, its ICE negotiation with the BOB UA.
+-------------+ |
| Alice | |
| UA WebCam | |
| | |
+-------------+ |
| |
| |
| |
+-------------+ +------\ +-------------+
| Alice | | | | |
| UA Audio :::::::| NAT |:::::::::::. BOB UA |
| +3pcc | | | | |
+-------------' +------/ +-------------+
|
|
On the other hand, if we want to use 3ppc, as showed on the picture above,
for sure the usage of 3pcc make transparent for the Bob UA the fact that
Alice is using
separate devices for different media,
but the Alice UA performing the 3pcc has to be involved also in the ICE
connectivity
check for the other Alice UA (the Alice UA WebCam in the picture) and
this fact
could complicate somehow the already not easy and light ICE negotiation
phase.
I believe ICE will work just fine in the 3pcc case.
Note that the SDP passed to Bob will have two m-lines - one for each of
Alice's devices. Because Alice has decomposed things, the Alice UA Audio
device will do the ICE on its audio device, and its Webcam will do the
ICE for the video. Bob's UA will do the ICE for both media. The picture
above is not quite right, because there will be media through the NAT
for both devices.
You ask how many UAs implement 3pcc. Maybe that is small. But its also
true that few devices support session correlation. It will take new
implementation to offer such a feature. Its just a matter of the most
viable way to do it. If I were building such a device/feature, I would
want to do it in a way that would maximize the possibility of interop
with any device supporting the same combination of media. Only
interoperating with devices that implement a new feature that is no
benefit to them seems like quite a limitation.
Thanks,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
