Re: [Sip] Early media as an endpoint application

[Dean Willis <dean.willis at softarmor.com>]

On Aug 24, 2008, at 3:52 PM, Christer Holmberg wrote:

>
> Probably the easiest to implement also. Because, if you would use  
> separate SIP sessions, you would need to somehow "transfer" the ICE/ 
> SRTP/resource reservation state between them.
>
> ...unless you want to perform separate ICE/SRTP/resource reservation  
> on the early- and the full dialog sessions, which would be really bad.
>

Good point.



>>> The issue with that solution is of course that a forking proxy, as
>>> currently defined, would terminate all other legs once the first 200
>>> OK (establishing the early media path of the session) arrives.
>>
>> One could of course change that behavior and have the forking proxy
>> return ALL responses.
>
> They do currently forward all 200 OK responses, but there will of  
> course only be multiple 200 OK responses if they were sent before  
> the CANCEL sent by the forking proxy arrived.

Right. I meant that the forking proxy would have to not prune the  
forks, and the UA might have to deal with multiple concurrent media  
sessions as a result.


>
> If you want to get rid of 100-rel there is also another way: get rid  
> of UDP ;)
>

I've suggested that from time to time. Very seriously.

However, you still need end-to-end reliability, because proxies might  
receive a message (satisfying TCP), but then drop it.

So one really has to eliminate UDP and proxies. I'm OK with that.

>>>> Consider instead that a forking node is really a "forking gateway",
>>>> not a proxy. It takes one call in, establishes a fully-negotiated
>>>> "early session",  then sends out its multiple INVITES.  As those
>>>> sessions (which might have early media) connect up, the forking
>>>> gateway deals with the multiple media streams (by bridging,
>>>> discarding, whatever).
>>>
>>> Doesn't that simply move the how-to-choose-which-early-media-stream-
>>> to-listen-to from the UAC to the forking proxy/gateway?
>>
>> It allows the forking gateway to either mix all the streams into one
>> (a boon to the bandwidth-restricted UAC), or more intelligently  
>> choose
>> which one to relay based on media-analysis. For example, ringing can
>> easily be differentiated from speech, so if a forking-b2bua sees four
>> legs of ringing and one of speech, it could quite reasonably choose
>> the speech channel to send back to the UAC.
>
> What if it sees four legs of speech and one of ringing?
>
> I agree that you could make the life of the UAC easier, and better  
> control that the media sent towards the UAC "fits" within the  
> negotiated UAC-proxy bandwidth etc, using this kind of forking-b2bua.
>
> But, it would require a big box, media mixing and possibly  
> transcoding, in the network, and someone told me that IETF is about  
> UA-to-UA-with-nothing-but-stupid-cable in between :)

See above discussion of eliminating proxies too .  . .

>
>
>>>> If we have to have forking, and we have to have media before  
>>>> there's a
>>>> final answer, then I think something like this is needed to make it
>>>> work.
>>>
>>> Again, it could make the signaling flows a little more nicer, and it
>>> would move some decissions from the UAC to the forking gateway, but
>>> the problem with multiple media streams (no matter whether you call
>>> them early or not :) would still exist.
>>
>> Perhaps. However, one of the more profound problems today (as with
>> mobile nets) is limited bandwidth to the UA. Dealing with mixing,
>> recoding, and selection-from-alternatives in a "server" is much  
>> easier.
>
> Yes, but saying that is not politically correct, is it? :)

Me, politically correct? Surely you jest.

--
Dean
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip