Subject: [MMUSIC] resusing ICE candidates

From: Vikram Bhuskute <[email-masked]>
Date: Mon, 27 Nov 2006 15:47:40 +0530

Hi All,
         While thinking on How to reduce the POST-Pickup delay etc.
Following are my thoughts.

1.) It should be a good idea  to re-use earlier ICE results ? ( Though
seems to be a Implementations botheration .. still good if can be kept
as a part of protocol )
In most of the cases I guess 60-70 % is re-dial to a earlier contacted
number . In such a case , do we really have to go through the entire ICE
process ? I do understand that network topologies can change but still
it is not a bad idea ?

2) While reusing the ICE candidates .... device can quickly perform a
check on its own network status ...  And using some indication in SDP It
can request the other party to check its network status too...
If the network topology  is unchanged ...( Type of NAT etc : which is
quite possible as NAT policies wont change so often..) ..Then just use
old candidates else Re-start ICE ?

Please comment on this ...
Please let me know If this is already part of discussion ...?

regards

Vikram

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: <[email-masked]>
Date: Mon, 27 Nov 2006 16:28:56 +0200

Hi Vikram,

I think there are many reasons that would cause the proposed
approach to fail:

- Most importantly NATs remapping the previously used addresses
  for some other client

- But also the local addresses of the device may change due
  getting new addresses from DHCP, like due to device reboot
  or mobile device attaching a new WLAN network

Thus the likelihood of the earlier results being valid seems
to be so low that you'd better to re-run ICE for every new call.

Regards,

Erkki 

>-----Original Message-----
>From: ext Vikram Bhuskute [mailto:[email-masked]] 
>Sent: 27.November.2006 12:18
>To: mmusic
>Subject: [MMUSIC] resusing ICE candidates
>
>Hi All,

---

From: Vikram Bhuskute <[email-masked]>
Date: Tue, 28 Nov 2006 12:37:46 +0530

Hi Erkki,
            See Inline.

> - Most importantly NATs remapping the previously used addresses

Agree ! But as in case of TURN/ICE , client  can keep its port Alive
with TURN server , In which case NAT binding should not change with a
new call if the NAT is of  "address independent Mapping" type. If NAT is
doing dependent mapping then even then same binding is useful as we will
do relay .

>   or mobile device attaching a new WLAN network
Agree ! But this can be easily and quickly found out . If there is any change 
restart the process else use the same.

Is it possible to think it a like a NAT FSM on the client ? 
If its State is unchanged (Depending on x,y,z parameter) reuse the
earlier result , else restart ICE.

I only see Some problem could be in  keeping the Relay address on STUN
server for longer time .

It is said that there is a trade-off between little delayed service and
no-service ...agree ..Now It has to be improved from here , In order to
have less overhead on everybody.

regards

Vikram