Subject: [MMUSIC] ICE and empty re-INVITE

From: Roman Shpount <[email-masked]>
Date: Wed, 15 Oct 2014 09:40:24 -0400

I guess, then my question is, should this group also address the
ICE-restart on empty re-INVITE as a separate item? It is extremely
inconvenient that the need for ICE-restart vs old ICE pair reuse cannot be
signaled when offer is requested.

_____________
Roman Shpount

On Wed, Oct 15, 2014 at 2:55 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
>
>
> To base solutions on the sending of empty re-INVITEs is in my opinion not
> a very good idea. Also, it makes things tricky for intermediaries that need
> the information. In order for them to trigger re-INVITEs they have to be
> B2BUA, and that will then cause other problems.
>
>
>
> What I suggest has very little impact on ICE as defined today. It only
> adds some kind of indicator (ice-options attribute value?) whether the
> second offer is needed or not. Simple :)
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* mmusic [mailto:[email-masked]] *On Behalf Of *Roman
> Shpount
> *Sent:* 14 October 2014 22:17
> *To:* [email-masked]
> *Subject:* Re: [MMUSIC] ICE updated offer
>
>
>
> Would the better solution for this entire problem be a SIP option that
> allows to suppress ICE restart on new empty re-invite? If both sides
> support this option (via the Supported header), then new offer is not sent
> in the end of the ICE process. If remote party needs it, then it can do an
> empty SIP re-INVITE with this flag set. If intermediary does not support
> this, they can remove the option from the Supported header in any direction
> and this will cause a new offer-answer transaction per old RFC.
>
> _____________
> Roman Shpount
>