Re: [Sip] Early media as an endpoint application

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi,

>>>Would these services be impossible if there were actually separate  
>>>SIP sessions for the "early" and "regular" sessions?
>>
>>Maybe not, but I am still not sure what problems you would solve by  
>>having separate sessions.
>
>
>By having a fully connected "offer/answer" completed session instead  
>of "early session", we  escape most of the state machine complexities,

Having worked with/implemented offer/answer state machines for many years, it really isn't that complex in my opinion. The problem is that people are often trying to "implement call flows", not taking forking and multiple early dialogs into consideration etc.

>resolve the "media before answer" pinhole opening and codec loading  
>problem, etc.

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.

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

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.

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

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

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

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? 

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

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

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?

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

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

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

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

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