Re: [rtcweb] Forking - Re: SDP Offer/Answer draft-jennings-rtcweb-signaling

[Cullen Jennings <[e-mail]>]

inline but yes, your understanding is what I was thinking 

On Oct 19, 2011, at 7:04 , Christer Holmberg wrote:

> 
> Hi, 
> 
>>> Did we decide to explicitly not support forking which 
>>> generates multiple final answers? If this is not the case, 
>>> how is this supposed to be implemented using your model?
>> 
>> I think that it is critical that we support what is needed to 
>> make a call that goes to 1-800-go-fedex work. So consider the 
>> following use case: A browser calls through a signaling GW to 
>> a sip that forks the call to an SIP to PSTN gateway and also 
>> to a voicemail server. The PSTN gateway generates an 180 with 
>> ringback tone but the SIP call is eventually answered by the 
>> voicemail server that sends a 200. 
>> 
>> So 3264 supports forking by an single offer may result in say 
>> two answers. In the case above, an single offer resulted in 
>> two different answers. Roap would support this type of 
>> transaction by allowing two answers to be received. There are 
>> two ways this can happen - one is with different 
>> answererSessionId in the the answers. Another is the use of 
>> the More-coming flag. We think with these, one can support 
>> the range of what 3264 allows for offer/ answer. 
> 
> - Assume my browser is communicating with a SIP gatway, and I use some non-SIP signalling protocol to transport ROAP messages between the browser and the gateway.
> 
> - The gateway maps ROAP into SIP, and a proxy forks the INVITE to multiple SIP UAs.
> 
> - When the gateway receives reliable 18x provisional responses, on different early SIP dialogs, it forwards them as final ANSWERs towards the browser.
> 
> - When the gateway receives the 200 OK, all other early dialogs are terminated. Now, from a pure ROAP perspective, the only way to inform the browser about that would be for the gateway to send new OFFERs for every terminated early SIP dialog, and e.g. indicate port=0.
> 
> Correct?

yes - I think that port=0 is the wrong way to indicate these have ended as it is confusing with hold and ending a particular media stream vs ending an offer/answer session. So this makes the argument for a better way to clean up state on the ROAP side. 

> 
> Now, instead of mapping the 18x provisional responses to final ANSWERs, the gateway could of course map them to non-final ANSWERs, and then later send final ANSWERs with an error code. But, the problem then is that the browser is not able to (or, at least that's my assumption - see separate e-mail) send a new OFFER until it has received a final ANSWER.

Yes - we have the same understanding of how with would work.  I imagine this would be the path most things takes. I don't see uses case where needing to send a new OFFER before receiving the final ANSWER would be a problem. 


> 
> Regards,
> 
> Christer
> 
>