Re: [Sip] Early media as an endpoint application

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

On Aug 24, 2008, at 7:25 AM, Christer Holmberg wrote:

>>
> The "media before answer" (if you refer to SDP answer) can be solve  
> by simply saying that one must send an SDP answer must be sent  
> before media is sent.
>
> The you-must-be-able-to-receive-media-once-you-have-sent-the-INVITE  
> doesn't work, because today media sent before SDP answer will often  
> be discarded anyway.
>

Perhaps not, but it's how ever device and service  I currently have  
works.

Not that they work well, mind you.

>> It also makes ICE and SRTP much easier to deal with. By
>> making the transition to "regular" session a re-invite  the gateway
>> can transition from send-only to send-receive (if needed), the  
>> billing
>> system (if it cares) can start the meter running, etc.
>
> So, just to clarify, you are still talking about a single SIP  
> session, right?

That's one of the two possible approaches, and probably the easiest to  
explain.


> 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.


>
>
> But, that would minimize multiple early media streams, which again  
> in my opinion shows that the main problem is not offer/answer, but  
> forking :)

The two certainly play poorly with each other.

>
>
>> Plus we can drop all the 100-rel and preconditions cruft out of the
>> state machine completely, making life MUCH better for the coder.
>
> If you separate the offer/answer state machine from the SIP  
> transaction state machine it shouldn't really matter in what SIP  
> messages the offers and answers are carried.

Perhaps true, but the SIP 100-rel state machine is profoundly ugly all  
by itself.

>
>
> And, eventhough we probably would be able to remove SDP from  
> provisional responses, I think provisional responses would still be  
> useful for other things (indicating ringing etc).

Yes, and provisionals also impact the resend timers. We need them. We  
just don't need 100-rel.

>
>
> But, of course we could have instead have used something like UPDATE  
> (or even INFO) to indicate "ringing" etc, instead of provisional  
> responses.
>
>> Think of it this way -- If I'm calling a PSTN gateway, do I really
>> want to wait until the PSTN side connection completes before I do the
>> setup work for SRTP? I think I'd rather get that out of the way  
>> before
>> the called party answers, or before I even see early media coming  
>> back
>> unprotected.
>
> What prevents you from doing the SRTP negotiation using reliable  
> provisional responses, in the same way you are able to perform  
> preconditions before the called party answers?

In my case, mostly the desire to avoid reliable provisional responses.

And when you cross-factor reliable provisional, SRTP, and forking, you  
get a real mess.

>
>
>> Now, lets think about forking. When we fork in a proxy, the UAC can
>> only deal with one "best answer", and early media is anybody's guess
>> as to how it might work or what might happen (it pretty much turns to
>> soup, especially if you get multiple early media channels).
>
> Correct. And, that will be a problem as long as it is possible for  
> the UAC to receive multiple early streams - no matter how they are  
> negotiated.
>
>> 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.

>
>
>> When a forked session matures to a "regular session", the forking  
>> gateway can re-invite the UAC to >make that session a "regular  
>> session",
>
> Today it does that again by sending 200 OK.

Right -- assuming you did your media setup in provisional (and keying  
in reliable provisional, which is messy)

> Again, I agree that many things probably could be done in a  
> "cleaner" way, but I think the main problem still exists: if there  
> are multiple early media streams (due to forking proxy or forking  
> gateway), how do I choose which one to play?
>

I'm not aware of a perfect asnwer, but (as above) can say there are  
definitely several "better" answers than what we have now.


>> or can even arrange to drop itself out of the media path if needed.
>
> How would that work? It would be able to change the local contact  
> from itself to the called party, but it would not be able to add the  
> possible Record-Routes between itself and the called user.

Media path, not signaling. Fall back to 3PCC setup techniques on a  
reinvite sequence.

>
> Not being able to modify the signaling path during a session (read:  
> update the Record-Route) is a "bug" in the protocol, I think, but  
> it's a separate issue :)
>

yeah, re-invite should be abele to re-route.


>> 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.

>
> In my opinion, the only solution, using what we have today, is to  
> make sure there is only one early media stream sent.

Yep. That's quite true. It's also very difficult, if anything forks.  
Our greatest power is our greatest problem.

--
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