Re: Comments on draft-loreto-sipping-context-id-requirements-00

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux