Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3)

[Christer Holmberg <[e-mail]>]

Hi Cullen, 

>>>> Q2. Are there restrictions when it comes to changing 
>>>> information in a non-final answer and a final answer? Or, can the final 
>>>> answer be completely different from previously sent non-final 
>>>> ANSWERS? In "legacy" O/A there are restrictions.
>>>> 
>>> Any answer has to be a valid answer for the offer but other than 
>>> that, no restrictions, so the final answer can change 
>>> everything from an earlier one.
>> 
>> Is there a reason/use-case/requirement why we need to allow 
>> that? As far as I know, the reason behind this is ICE.
>> 
> There a bunch of use cases but to mention two: In the browser 
> to browser case, imagine that you start sending audio in the 
> first answer but need to wait for user feedback to find out 
> if video can be added or not in the final answer. In a 
> browser to SIP use case, the early media for 1-800-go-fedex.

I think that could cause interoperability issues.

For example, assume that a gateway would map a more-to-come answer to a SIP 18x response.

Then, if the no-more-to-come answer is different, the gateway can't map it to SIP 200 response - at least not without chaning the SIP dialog identifier.

Also, if you map a more-to-come answer to a SIP 18x answer, and then receives a new SIP offer, the gateway *cannot* map it to a ROAP offer, as it is still wating waiting for the no-more-to-come answer.

Regards,

Christer