Subject: RE: [Sipping] Some thoughts on fixing early media: Receive media after INVITE is sent

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 19 Jul 2006 16:06:42 +0200

Hi, 

>>I have never really understood the receive-media-as-soon-as-you- 
>>have-sent-the-INVITE "rule", and the only justification I've recently 
>>heard is that it's "the spirit of SIP" to do so... Maybe the initial 
>>reason for the rule was that we didn't have reliable provisional 
>>responses, clear offer/answer procedures etc at that time, and/or 
>>maybe we even had PSTN interworking in mind. But, today we are in 
>>another situation, and the question is whether it's really needed and 
>>usable.
>
>The real justification for this rule is that the return path to the UA
for signaling is usually slower (it goes through 
>proxies) than the return path for media.
>
>So if Alice calls Bob, and Bob picks up the phone and says "hello",
Bob's RTP is racing against and likely to beat his 
>200 OK back to Alice. So Alice's UA had better be ready for media when
it sends the INVITE. Or Bob will be left saying 
>"Hello? Hello? Click".

First, I think that is mostly a theoretical problem, because in most
cases there will always be a delay before Bob actually sends some media.
Of course, it make take an extra long time for the 200 OK to reach the
UAC, but that can be solved with reliable provisional responses, when
you can send the SDP answer in a 18x (even if you don't use reliable
provisional responses the UAS can send SDP in a unreliable 18x, which
the UAC can use if it receives it).

Second, the problem can easly be fixed with a few lines of code, at
least if you use reliable provisional responses. Just send a reliable
18x with SDP and wait for a while before you alert the called user. And
even if the UAS does not wait before alerting the user, in most cases it
will take some time before the called party picks up the phone, so the
18x will reach the UAC before the media.

>We do have the limitation that Alice can listen but cannot SEND media
to Bob until Bob has sent an SDP answer. 

At some point we even tried to get around the rule by saying that the
UAC must be able to receive media once the INVITE has been sent, but not
necessarily play it to that user. That, and the fact that a number of
products and network architecutres require an SDP answer before
accepting early media, makes the rule quite useless. Becuase, one can't
be sure that the UAC user really would hear the media sent before the
SDP answer... We can blame it on bad implementations, bad network
architectures, or whatever, but it's how the world looks today. And one
reason for that is probably because the rule is more pain than gain.

>In some cases, this could be a problem -- we might see a 5 second delay
on the 200 OK on some mobile nets. Thats not as 
>bad as it sounds, because those mobile nets aleady have that kind of
delay, and people have gotten used to it, mostly.
>>However, EVEN if we require an SDP answer before we send media, we 
>>don't know whether there is actually going to be any early media, and 
>>in forking cases having that kind of information (whether it's a P- 
>>header or something else) could be helpful in many cases.
>>
>Yep, The issue is that of backward compatibility -- if you fork to a
destination without knowing whether that destination 
>will play nice with an early-media response, you're back where you
started. So we need a way for a forking proxy to 
>insert an option-tag into a Require that forces any UA not
understanding play-nice-early-media to reject the request. The 
>forking proxy (or user thereof) then has to figure out how to deal with
the broken destination.

What do you mean by play-nice-early-media?

Also, if you put something in a Require header, and the receiver doesn't
support it, it will reject the request. Is that what we want to happen?

Regards,

Christer

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP