1 / 7

IETF 80 MMUSIC WG draft-elwell-mmusic-ice-updated-offer

IETF 80 MMUSIC WG draft-elwell-mmusic-ice-updated-offer. Thomas Stach John Elwell Andy Hutton. Background. Discussion during last year on barriers to implementing ICE Alternative proposals for IPv4/IPv6 negotiation https://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/

jana-callahan
Download Presentation

IETF 80 MMUSIC WG draft-elwell-mmusic-ice-updated-offer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF 80 MMUSIC WGdraft-elwell-mmusic-ice-updated-offer Thomas StachJohn ElwellAndy Hutton

  2. Background • Discussion during last year on barriers to implementing ICE • Alternative proposals for IPv4/IPv6 negotiation • https://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/ • https://datatracker.ietf.org/doc/draft-hutton-mmusic-icemicrolite/ • Bar BoF at IETF#78 • Present draft discusses a couple of issues not previously raised • Purpose: to get feedback on whether these issues need to be addressed and how

  3. Issue 1 – Interaction with fax UA1 (call ID owner) UA2 • Collisions between ICE updated offer and attempt to switch media on fax detection • back-off and randomized delay before trying again • Potential failure of fax, through • inability to switch media before fax machine times out) or • middleboxes blocking media flow because SDP not updated in time INVITE / offer audio 183 / answer audio ICE negotiation 200 / answer audio Fax detected ICE requires updated offer UPDATE / offer image UPDATE / offer audio 491 491 Back-off, 0-2s. UPDATE / offer image Back-off, 2.1-4s. 200 / answer image UPDATE / offer image 200 / answer image

  4. Issue 1 – Possible Remedies • Delay ICE updated offer • UA1 doesn’t know fax will be detected • Delay fax updated offer • Difficulty choosing how long to delay, to allow time for receipt of ICE updated offer without being too late for fax to work • Always require the ICE update so that fax UA will expect it • Change to ICE spec • Still won’t work under all conditions • Use pre-conditions to prevent media flow before ICE updated offer • Change to ICE spec • Heavy burden of having to support 100rel and pre-conditions

  5. Issue 2 – Interaction with 3PCC • 3PCC call establishment in accordance with RFC 3725 Flow I is commonly implemented • With this flow, the ICE updated offer is not possible in a timely manner, because the state of the second leg does not permit UA1 B2BUA UA2 INVITE 200 / offer INVITE / offer ACK / answer 183 / answer ICE requires updated offer ICE negotiation UPDATE / offer What next?

  6. Issue 2 – Possible Remedies • Avoid 3PCC • Not feasible – REFER, for example, doesn’t work when sent to PSTN gateways • Delay ICE updated offer • UA1 unaware of status of INVITE transaction to UA2, so doesn’t know how long to delay • Delay ICE until UA2 answers • How would UA2 know it has to do this? • Clipping of media • Use 100rel and UPDATE for forwarding the updated offer to UA2 • Raises the bar • UA2 is a 3PCC-unaware UA, so how would it know it has to do this?

  7. Conclusions • Two cases of bad interactions caused by the ICE updated offer • Any other suggestions for work-arounds? • Do we really need the ICE updated offer • How many middleboxes work well with the updated offer but would not work without it? • Or putting it another way, how many middleboxes would still fail with the updated offer (e.g., rejecting it)? • It is only SHOULD for cap-neg, so why MUST for ICE?

More Related