Re: [rtcweb] Agenda requests for Atlanta meeting

["Cullen Jennings (fluffy)" <[e-mail]>]

Well, what's the end user experience you're trying to achieve  - lets say we are talking about audio. Do you want to play the first one or the last one? If you want to bridge them into a party line, this is probably not how you want the SIP side to happen. 



On Oct 8, 2012, at 18:24 , Roman Shpount <[e-mail]>
 wrote:

> 
> 
> On Mon, Oct 8, 2012 at 8:42 PM, Cullen Jennings (fluffy) <[e-mail]> wrote:
> 
> Check out text from RFC 3311 that says
> 
>       o  If the UPDATE is being sent before the completion of the INVITE
>          transaction, and the initial INVITE contained an offer, the
>          UPDATE cannot be sent with an offer unless the callee has
>          generated an answer in a reliable provisional response, has
>          received a PRACK for that reliable provisional response, has
>          not received any requests (PRACK or UPDATE) with offers that it
>          has not answered, and has not sent any UPDATE requests
>          containing offers that have not been answered.
> 
> So the 183 would be need to be sent reliably at which case I would expect the gateways to map it to a final offer in RTCWeb not a provisional one. At that point when the update comes along with an offer, it just mapped to RTCweb offer.
> 
> 
> And what happens with the next 183 or 200 OK sent reliably in a different dialog? When we are dealing with serial forking we are dealing with different sequential dialogs created by the same offer, aren't we? Otherwise this is not really standard compliant. 
> _____________
> Roman Shpount
> 
>