Subject: RE: [Sipping] Some thoughts on fixing early media

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 18 Jul 2006 23:39:32 +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.

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.

Regards,

Christer

-----Original Message-----
From: Dolly, Martin C, ALABS [mailto:[email-masked]] 
Sent: 18. heinäkuuta 2006 18:35
To: Hadriel Kaplan; Brian Rosen; Dean Willis; Stephen Sprunk
Cc: sipping
Subject: RE: [Sipping] Some thoughts on fixing early media

I agree 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Tuesday, July 18, 2006 11:33 AM
To: 'Brian Rosen'; 'Dean Willis'; 'Stephen Sprunk'
Cc: 'sipping'
Subject: RE: [Sipping] Some thoughts on fixing early media

Aren't you just redefining what/when early media is?  If you say media doesn't start until 200ok, then you have to have a message after 200ok for billing.  So the time between those is now "early media".  And providers will need a way to know when such un-billed early media is allowed or not, and we're back to square one.

Unless you're just trying to get rid of the idea of media before an SDP answer.  If that's the case, why not just say "no media until an SDP answer", and let 18x do it.  To me the *pre-answer* early media is the broken early media.  And I think it's pretty much the case now anyway - PSTN gateways generally don't play media until they get a 18x w/SDP anyway, ICE doesn't work without it, sec-descriptions don't work without it, etc.

Either way doesn't avoid the fact that there's media before billing that needs to be played or not, depending on the type of UAS that answered.

-hadriel

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, July 18, 2006 10:58 AM
> To: 'Dean Willis'; 'Stephen Sprunk'
> Cc: 'sipping'
> Subject: RE: [Sipping] Some thoughts on fixing early media
> 
> This is probably the right direction, but what do you really do with
the
> media in the forking case?  Let's say you had two gateways, the call
was
> forked to both of them, and early media came from both of them?
> 
> Both send 200 OK.  This is probably acceptable, although I suspect
most
> UAs
> won't appreciate it.  Eventually, one is going to hang up, and the
other
> is
> going to keep going (and send the "Billing Starts" message).  From a
sip
> standpoints, that's probably okay.
> 
> But what do we do with the media?
> 
> I'd clearly trade a "Billing Starts" message for deprecating early
media.
> Wouldn't even have to be a P-header.
> 
> Brian
> 
> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, July 17, 2006 6:25 PM
> To: Stephen Sprunk
> Cc: sipping
> Subject: Re: [Sipping] Some thoughts on fixing early media
> 
> 
> On Jul 14, 2006, at 1:59 PM, Stephen Sprunk wrote:
> 
> >
> > Forcing a 200 OK when the called party hasn't actually answered just 
> > to have a "real" media stream changes the problem, and causes the 
> > caller and callee all sorts of billing problems which they're 
> > unlikely to accept.  An IETF directive of "don't do that" isn't 
> > going to get companies to accept millions of minutes per year in 
> > toll-free charges they're not paying today.
> >
> 
> Nobody I know of has suggested that the operators and their customers 
> should exchange different amounts of money just to accomodate SIP 
> interworking.
> 
> But billing off of the 200 OK is broken and hard to fix. There needs 
> to be a separate indicator for "start of billing" that is not 
> necessarily coupled to the "start of media". Why? Because the start of 
> media and the start of billing are decoupled on the PSTN, and we have 
> to interwork with that model.
> 
> Fixing the billing problem is easier than fixing the psychic early 
> media problem.
> 
> So, let's keep the 200OK as SIP's "Yes, I accept your offer, let's 
> have a session" mechanism and do something else to handle the PSTNs "I 
> want to start charging you now" problem.
> 
> --
> Dean
> 
> 
> _______________________________________________
> 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
> 
> 
> _______________________________________________
> 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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Jul 2006 17:43:58 -0500

On Jul 18, 2006, at 4:39 PM, Christer Holmberg ((JO/LMF)) wrote:

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

We do have the limitation that Alice can listen but cannot SEND media  
to Bob until Bob has sent an SDP answer. 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.

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 19 Jul 2006 00:58:40 +0200

> out how to deal with the broken destination.

Accept-Contact: *;extensions="early-media";require;explicit

would avoid the request to be forked to elements that dont play along

Jeroen

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 24 Jul 2006 10:03:03 -0500

Thus spake "Dean Willis" <[email-masked]>
> INVITE. Or Bob will be left saying "Hello? Hello? Click".

However, Bob's UA has no idea whether the 200 made it to Alice or not until the ACK shows up, therefore to be safe it shouldn't send media until that point otherwise it risks being "early media" (and having all the attendant NAT/FW problems).  However, that moves the problem to the other end -- now Alice may start talking and the media gets lost because the ACK hasn't made it to the other end yet.

This is probably the best justification for early media I've seen -- in the normal case where there's no forking (and even in many cases where forking is used), the media path is established in both directions before the 200/ACK exchange, so audio cut-through delays are hidden in the early media where they're less likely to be noticed.

> aleady have that kind of delay, and people have gotten used to it,  

I've seen up to 500ms audio cut-through delay on _wired_ networks because the proxy/B2BUA takes an inordinate amount of time to forward the 200 and ACK messages.  That's not much compared to a mobile network, but it's enough to get complaints from some users.

> out how to deal with the broken destination.

IMHO, it's too late to make such a non-trivial change except on private networks where there's a reasonable chance the operator can upgrade all of the devices at the same time.  And I'm still not convinced it's needed; early media mostly works today, and the case where it's broken (parallel forking) today seems to still be broken with this proposal.  There's simply no way for any of the devices involved to know which of several early media streams to play.  If there's only one early media stream, it works fine already.

S