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

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Thu, 13 Jul 2006 18:29:22 +0200

Dean,

With regards to your proposal below, having a SIP indication is more effecient than having to do a entire new offer/answer exchange via "re-INVITE". Another comment is that early media can sometime be bidirectional (e.g. for collecting DTMF in the foward direction) so "sendonly" is not appropriate. The only way would be to indicate "inactive" in the reliable SDP answer for "non early-media" cases and then send re-INVITEs for setting up the media session...

sébastien

-----Message d'origine-----
De : Dean Willis [mailto:[email-masked]] 
Envoyé : jeudi 13 juillet 2006 17:17
À : sipping
Objet : [Sipping] Some thoughts on fixing early media

To recap:

Early media entered our vocabulary when we were first figuring out PSTN interworking.

Assuming I remember the PSTN terms correctly, in our rather naive attempt, we mapped  an INVITE to an IAM (Initial Address Message), a 180 to an ACM (Address Complete Message), and a 200 OK to an ANS (Answer).

The problem is, the PSTN often sends one way media from the answering side to the originating side between ACM and ANS. This often happens with announcement messages from the terminating switch, like "The party you have called is no longer in service."

So we said "ok, we'll just require the originator to receive and render media sent to their any of their offered address/port/codec entries."

Of course, this doesn't work with forking, because you might get MANY streams concurrently, then have to decide how to render them. My response was to suggest we deprecate forking. But we didn't.

And of course the PSTN people latched onto the 200OK as the "please start billing" request.

So, now we have a situation where early media always breaks with forking, often breaks with real network topologies, and can't be supported right by UAs that have to offer multiple codecs but can only execute one at a time, and the wight of the billing mechanism keeps us from fixing things.

So how do we fix it?

Here's a proposal, building on Rohan's proposal of about 5 years ago:

If a UAS is going to send media, it must first reliably send an SDP answer (as per offer/answer) in response to the INVITE.  Typically, we might expect to see this answer in a 200 OK. This might be sendonly if we're in an early-media situation, and it's reasonable to see that SBCs or MGCF or whatever could enforce the "sendonly"  
modifier to prevent toll fraud. If the call then moves to an "answered" state, we'd re-INVITE to move to bidirectional media. This is no more complicated than the standard mechanism for putting someone on-hold, so it should be quite doable.

If this breaks the billing, we just need to fix the billing model and apparatus. Really, it's not our fault. We told the PSTN people many, many times that billing off of the SIP signaling was unwise. But I assure you, it would be easier to hack billing start-stop functions into P-headers than to fix early media using a P-header.

But what about forking? It's been mentioned that if one forks a request to multiple destinations, and one of those is a PSTN gateway, and that gateway generates ringback using early media, the resulting 200 OK will always cause the forked call to terminate on the PSTN.  
This happens in large part because the forking proxy doesn't send all the responses back to the UAC, just the "best one",  and we think 200 OK is a "pretty good" response to return.

I see two possible paths forward:

1) Fix forking so that all responses are forwarded to the UAC. I believe Dale has a draft that suggests exactly this approach. The UAC could then sort out which of many responses it might want to deal with, and could potentially enter media relationships with several UAS simultaneously if needed.

2) Use preconditions. This would result in the PSTN GW doing early- media placing its offer into a reliable 18x (183 maybe?).  The forking proxy could then figure out reasonable processing, including possibly either responding to or delaying the 18x in hopes of getting a "real" 200 OK.

Of course, it might also be possible to combine the two approaches.

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 Jul 2006 16:18:47 -0500

On Jul 13, 2006, at 11:29 AM, GARCIN Sebastien RD-CORE-ISS wrote:

> Dean,
>
> With regards to your proposal below, having a SIP indication is  
> more effecient than having to do a entire new offer/answer exchange  
> via "re-INVITE". Another comment is that early media can sometime  
> be bidirectional (e.g. for collecting DTMF in the foward direction)  
> so "sendonly" is not appropriate. The only way would be to indicate  
> "inactive" in the reliable SDP answer for "non early-media" cases  
> and then send re-INVITEs for setting up the media session...

I'd argue that if you're engaging in "early media" using  
bidirectional media flow, you really need to have delivered an SDP  
answer so that the UAC knows what kind of media it can send.

--
Dean

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 14 Jul 2006 16:22:00 +0200

>answer so that the UAC knows what kind of media it can send.

Well -- I think that early media has been frequently bidirectional in 
the field just for the sole reason that a UAC cannot easily receive
packets from behind NAT it it hasnt send any packet out before.

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 14 Jul 2006 13:59:00 -0500

Thus spake "Jiri Kuthan" <[email-masked]>
> packets from behind NAT it it hasnt send any packet out before.

That's one reason.  Another is that by sending bidirectional early media, 
you get all the firewalls, flow cache entries, etc. set up along the path 
_before_ the callee answers rather than delaying the audio for a few hundred 
ms _after_ they answer (real world measurements).

The last, and equally important to the first, is that many IVR systems out 
there send menus and such in the early media and need return DTMF (also in 
the early media) before they'll _ever_ connect.  Without 3-5 minutes of 
bidirectional early media, you simply can't get through to some companies 
(mostly banks and airlines, in my experience).  If you want to ship a 
product today, you _have_ to support this brokenness.

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.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 14 Jul 2006 15:40:07 -0400

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> 

I think the term "early media" is ambiguous and causing confusion.  There's
pre-answer media, which obviously only works in one direction.  Then there's
post-answer pre-200 media (e.g., 18x-response), which can be bi-directional.
I think the fraud issue is mostly relevant to the latter case, and that's
the one the draft is about.  So yes, an SDP answer is delivered.

In the field typically a UAC thinks there's bidirectional post-answer
early-media

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 17 Jul 2006 17:24:38 -0500

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Jul 2006 10:58:11 -0400

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

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Jul 2006 11:32:35 -0400

Hadriel Kaplan wrote:
> the one the draft is about. 

The draft applies to both one-way and two-way media. The one-way cases 
include in-band ringback as well as error messages. Losing even the 
one-way media can result in missing important info.

	Paul

> So yes, an SDP answer is delivered.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 18 Jul 2006 11:32:54 -0400

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

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

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Tue, 18 Jul 2006 10:34:51 -0500

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.

-hadriel

> 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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Jul 2006 12:48:27 -0400

Nope.  200OK means "session established, media may flow", just like it's
supposed to.  It fixes all of the problems we have with early media (other
than multiple early media streams due to forking).

Creating an explicit call state which is between "session established" and
"Billing may start" actually allows you to do what you want, instead of
inferring what you should do from incomplete information.  You don't want
(read that as "don't trust") the UA to enforce any "before billing starts"
behavior; you guys insist on a box to do that, so we don't change anything
there, and can't, except to make it explicit when you enforce such limits.

But, letting the sip call state actually establish a session before media
flows is a big step in the right direction.

Brian

-----Original Message-----
From: Dolly, Martin C, ALABS [mailto:[email-masked]] 
Sent: Tuesday, July 18, 2006 11:35 AM
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

-hadriel

most
other

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 18 Jul 2006 20:44:29 +0300

Brian Rosen writes:

 > inferring what you should do from incomplete information.  

i don't see any reason for SIP messages for billing support.  since this
early media billing problem is related to pstn, people can always do
their billing on pstn side of their sip-pstn gw.

-- juha

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 18 Jul 2006 13:51:15 -0400

> than multiple early media streams due to forking).

Then define to me what problems you think we have with early media.  To me
the problems are:
1) There's pre-sdp-answer early media, which doesn't work half the time
anyway, billing or not.  Fix: deprecate pre-sdp-answer early media. 

2) There's a need for pre-call-answered media, which needs to be played iff
the UAS is of the right "type" (i.e., trusted-for-it).  This is not solved
by a 200ok-only media.

3) There's a need for indication when media is not early; i.e., when the
"call" is established because a human answered, and they're not going to be
busy, for PSTN/H.323/pick-a-flavor interop.  If (call_established !=
session_established) then I presume (call_established == start_of_billing)?

> there, and can't, except to make it explicit when you enforce such limits.

I'd actually prefer a box in the middle NOT have to do this - that the
PSTN-GW UAC do it on its own. (it's not our raison d'etre)  Regardless, the
call state needs to be _before_ session established, unless you're
suggesting a human answering a call triggers a second message after a 200ok?
So you establish a session even if the user ends up being busy?

> flows is a big step in the right direction.

Why?  If you're going to let multiple 200ok's come back, and another message
mean "now she answered the call", what's the diff from just using a 183?
The semantics need to be such that when a human being answers a call,
billing starts.  If 200ok no longer means the call was answered then we're
just mapping the 183 response code. (ok, state machine stuff changes too,
but not in a good way)

It's also too late for this type of change.  The ship has sailed.  SIP is
deployed.  People already use pre-200 media for legitimate uses.  The
question here is how to tell if they're allowed to.  I know the concepts of
legitimate and allowed are rather bizarre without context, but that's why
it's a P-header for private network use.

-hadriel

---

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

On Jul 18, 2006, at 9:58 AM, Brian Rosen wrote:

> most UAs
> other is

That's where a two-phase model comes into play.

Let's discard SIP syntax and talk about it at a higher level -- maybe  
that will help.

Let's say I place a call, and it is delivered to 4 recipients, all of  
whom wish to send "early media".

Each sends back a request to send early media, possibly with some  
additional information about the early media (like "custom ringing  
tone", "PSTN early media", etc.).

I can't listen to 4 media streams at once, so I pick one (possibly  
using the additional information they sent), and I tell that early- 
media source to go ahead.

Assuming the early media doesn't lead me to establish a session, I  
then tear down that leg and tell the next  early-media source to go  
ahead.

Repeat until I establish a session, then I tear down all remaining  
legs (if any) without having heard their early media.

What would this look like in SIP?

Here's a rough outline. I'm sure somebody can do better. The idea  
here is to do a "media starts" using provisional reliable messages  
and a "billing starts" using 200 OK.

I send an INVITE with a new early-media precondition tag. It is  
forked 4 ways. Each recipient responds with a reliable 18x including  
an "early-media request" tag,  possibly including an SDP answer (for  
bidirectional or "early session" media), and possibly including an  
early-media usage description modifier of some sort.

I pick one of the 4 responses and send a PRACK with an early-media - 
accepted tag. I defer sending PRACK to the other nodes. The node  
receiving the PRACK starts sending its early media. Assuming we don't  
end up moving to a session (with a 200 OK/ACK), somebody CANCELs this  
leg, and we go on to the next one.

Eventually,  we either set up a session with one of the respondents  
and CANCEL the remainder, or we time out the prov-rel and they give  
up, or we end up CANCELing all of the legs and give up ourselves, or  
some combination thereof.

Crazy, huh?

An alternative model, not using preconditions, would be to do the  
"media starts" with 200 OK, and then do a re-INVITE for "billing  
starts".

--
Dean

---

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

Dean,

see inline

Regards,

Jeroen

----- Original Message ----- 
From: "Dean Willis" <[email-masked]>
To: "Brian Rosen" <[email-masked]>
Cc: "'sipping'" <[email-masked]>
Sent: Wednesday, July 19, 2006 12:32 AM
Subject: Re: [Sipping] Some thoughts on fixing early media

> additional information about the early media (like "custom ringing  tone", 
> "PSTN early media", etc.).
>
> I can't listen to 4 media streams at once, so I pick one (possibly  using 
> the additional information they sent), and I tell that early- media source 
> to go ahead.
>
> Assuming the early media doesn't lead me to establish a session, I  then 
> tear down that leg and tell the next  early-media source to go  ahead.
>
> Repeat until I establish a session, then I tear down all remaining  legs 
> (if any) without having heard their early media.
>
>
> Here's a rough outline. I'm sure somebody can do better. The idea  here is 
> to do a "media starts" using provisional reliable messages  and a "billing 
> starts" using 200 OK.
>
> I send an INVITE with a new early-media precondition tag. It is  forked 4 
> ways. Each recipient responds with a reliable 18x including  an 
> "early-media request" tag,  possibly including an SDP answer (for 
> accepted tag. I defer sending PRACK to the other nodes.

An issue here is that the other nodes will keep retransmitting their 18x 
responses. So instead of deferring PRACK, better to send one with SDP 
describing the equivalent of "early media on hold", for each other node. The 
UA could then use UPDATE to select the next one to play, etc

>The node  receiving the PRACK starts sending its early media. Assuming we 
>don't  end up moving to a session (with a 200 OK/ACK), somebody CANCELs 
>this  leg, and we go on to the next one.

You will need BYE, not CANCEL (which would kill all legs)

>
> Eventually,  we either set up a session with one of the respondents  and 
> CANCEL the remainder, or we time out the prov-rel and they give  up, or we 
> end up CANCELing all of the legs and give up ourselves, or  some 
> combination thereof.
>
>
> Crazy, huh?
>
> An alternative model, not using preconditions, would be to do the  "media 
> starts" with 200 OK, and then do a re-INVITE for "billing  starts".
>
> --
> Dean
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 19 Jul 2006 01:03:45 +0200

> You will need BYE, not CANCEL (which would kill all legs)

That is, if the UA would be doing it. A proxy would automatically CANCEL 
other branches once one of them sends 200 OK to the INVITE. So all that is 
needed is a way for the UAC to "invite" the selected UAS to do that (it 
implies that things break down once one of the contacted UAS sends 200 OK 
before being elected, unless the UAC uses Request-Disposition: no-cancel)

Jeroen

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Jul 2006 18:53:52 -0500

On Jul 18, 2006, at 6:03 PM, Jeroen van Bemmel wrote:

>>> The node  receiving the PRACK starts sending its early media.  
>>> Assuming we don't  end up moving to a session (with a 200 OK/ 
>>> ACK), somebody CANCELs this  leg, and we go on to the next one.
>>
> That is, if the UA would be doing it. A proxy would automatically  
> CANCEL other branches once one of them sends 200 OK to the INVITE.  
> So all that is needed is a way for the UAC to "invite" the selected  
> UAS to do that (it implies that things break down once one of the  
> contacted UAS sends 200 OK before being elected, unless the UAC  
> uses Request-Disposition: no-cancel)
>

Yep. I'm still up in the air about whether it's the UAC or the  
forking proxy that has to manage the cleanup. I suppose it would be  
cleaner at the UA, but maybe there's a way to get backward  
compatibility for old UAs just using the proxy . . .

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 19 Jul 2006 02:21:11 +0200

>> other branches once one of them sends 200 OK to the INVITE.  So all that 
>> is needed is a way for the UAC to "invite" the selected  UAS to do that 
>> (it implies that things break down once one of the  contacted UAS sends 
>> 200 OK before being elected, unless the UAC  uses Request-Disposition: 
>> no-cancel)
>>
>
> Yep. I'm still up in the air about whether it's the UAC or the  forking 
> proxy that has to manage the cleanup. I suppose it would be  cleaner at 
> the UA, but maybe there's a way to get backward  compatibility for old UAs 
> just using the proxy . . .

I doubt we would manage to play this "red light / green light game" in a 
backwards compatible way. If this requires changes at the UAC anyway, the 
cleanup would become just a minor addition.

Some other considerations:
In the current PSTN, what you can have is the following early media "This 
call will be charged at international dialing rates. If you don't wish to be 
charged, please hang up now [delay] [charging starts]"

In other words: opt-out. In SIP, this would translate to the UAS 
automatically sending 2xx (and the proxy cancelling other branches) after a 
delay, after playing its early media.

If we want opt-in, the SIP equivalent would be to have the UAC explicitly 
say "accept", for example using an UPDATE request (containing an offer for 
the "late media", and some flag triggering the UAS to send 2xx). This would 
not be backwards compatible.

The only way I see to do such opt-in in a (kind of) backwards compatible 
way, is to use some "press 1 to accept" tune and INFO or RTP with DTMF (or 
SUBSCRIBE/NOTIFY with KPML if you consider that as backwards). It seems that 
all of these quickly become "backwards complexity"

Regards,

Jeroen

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 18 Jul 2006 20:09:54 -0500

Thus spake "Dean Willis" <[email-masked]>
> receiving the PRACK starts sending its early media. Assuming we don't  end 
> up moving to a session (with a 200 OK/ACK), somebody CANCELs this  leg, 
> and we go on to the next one.
>

That's rather similar to what our UAC does today, actually.

1. Send INVITE, which gets forked to N destinations.
2. By default, all incoming RTP is dropped.
3. Up to N destinations reply with 183.
4. We PRACK the first 183 to come in.
5. Send/receive RTP according to that 183's SDP (i.e. ignore RTP coming from 
any other IP/port)
6. Ignore all other 183s (do not PRACK).
7. When a 200 comes in, we ACK it.  If the 200's SDP is different than the 
PRACKed 183's SDP, switch to the new SDP.
8. The proxy CANCELs the other legs.

The above has the disadvantage that early media is required to be 
bidirectional, but for NAT/FW and security reasons we considered that a 
feature, not a bug.

This seems to work as well as can be expected when forking is used and no 
other information is available to pick which 183 is "best".  That'd 
certainly be a nice enhancement, but it's not necessary in the use cases I 
deal with -- first response seems to work for us.  If others would like to 
add some sort of indication what type of media a 183 is providing, that may 
make things easier for other folks.

S

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 19 Jul 2006 09:26:40 +0300

> delay, after playing its early media.

why can't pstn gw sent 200 ok instead of 18x and then wait until [delay]
has passed before it sends "start" accounting request?

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 19 Jul 2006 08:36:53 +0200

Juha,

Sure, it could do that. Drawback is that you could loose other pending 
branches, if any (and proxy is not instructed otherwise)

That reminds me - I've wondered if it would be handy to get an indication in 
a request that it has been forked. This could make a responder aware of such 
possible consequences, and enable policies like delaying a 2xx answer.

Regards,

Jeroen

----- Original Message ----- 
From: "Juha Heinanen" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "Dean Willis" <[email-masked]>; "'sipping'" 
<[email-masked]>
Sent: Wednesday, July 19, 2006 8:26 AM
Subject: Re: [Sipping] Some thoughts on fixing early media

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 19 Jul 2006 09:47:15 +0300

> branches, if any (and proxy is not instructed otherwise)

but since early media doesn't currently work with forking, what exactly
would be the drawback?

-- juha

---

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

Well, if the PSTN call would go to voicemail, for example, it would be nice 
if the user would be informed, and enabled to BYE it and give other branches 
a chance.

The inform could come as early media ("this is the voicemail of...") or 
(perhaps better) a 183 SIP response, with an internationalized message "your 
call is being answered by voicemail"

With a 2xx the above would not work

Regards,

jeroen

----- Original Message ----- 
From: "Juha Heinanen" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "Dean Willis" <[email-masked]>; "'sipping'" 
<[email-masked]>
Sent: Wednesday, July 19, 2006 8:47 AM
Subject: Re: [Sipping] Some thoughts on fixing early media

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 19 Jul 2006 10:17:25 +0300

Jeroen van Bemmel writes:

 > if the user would be informed, and enabled to BYE it and give other
 > branches a chance.

so are saying that the called party has registered several contacts with
the same q value, one of which is voicemail contact and others are
regular phone contacts?  if so, this problem can be solved with giving
voicemail contact lower q value (like it is also in pstn).

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 19 Jul 2006 09:48:13 +0200

Juha,

> voicemail contact lower q value (like it is also in pstn).

No, I don't think so, for 2 reasons:

1: If the voicemail is behind a PSTN gateway, like in the scenario I 
sketched, the registered contact on the SIP side is for the PSTN number. It 
may or may not go to voicemail, and you may not have any means to control 
this from the SIP side (unless you would register a dedicated PSTN voicemail 
number of course, for sake of argument let's assume that is not available)

2: the q-value is a callee preference, whether I want to leave a voicemail 
or not is a caller preference.

(and 3 : lower q-value does not guarantee that a proxy will fork serially, 
but let's assume the proxy plays along)

One could include caller preferences that say "don't go to voicemail", but 
again you may not have control over that when going to PSTN, and moreover as 
a caller I do not want to even think about this decision until I am 
confronted with it (and anyway including prefs for all possible outcomes is 
infeasible)

Regards,

Jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 19 Jul 2006 10:13:30 +0200

> > this from the SIP side (unless you would register a dedicated PSTN
> > voicemail number of course, for sake of argument let's assume that is
> > not available).
>
> i have never called someone on pstn and had a change to decide for free
> if i want to get connected to voicemail.
>

Exactly! So this to me is behavior that should not be copied or emulated or 
simulated. It is one of many areas where SIP could provide a better user 
experience

> but even if there were such an announcement, early media with forking is
> not working anyway and my original question is still not answered: what
> currently working would we loose be allowing sdp only in 200 ok?

You loose early media in the non-forking case. And you can't (currently) 
restrict it to "when answering a forked request, put SDP only in OK" because 
the gateway cannot distinguish a forked request.

jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 19 Jul 2006 10:57:59 +0300

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2006 12:48:49 -0400

> currently working would we loose be allowing sdp only in 200 ok?

- early media works passably, even through gateways,
   if some middlebox doesn't intentionally mess it up.

- Forking works

Unfortunately they don't work well *together*.

Something that "fixes" early media should at least provide the 
functionality that currently works. Something that "fixes" forking 
should also at least provide the functionality that currently works.

Maybe an adequate solution won't be backward compatible with the 
existing mechanisms. That isn't ideal, but might be acceptable if it 
brought enough benefits.

A basic problem today is that the major source of early media is 
gateways, and they don't know what the semantic content of the early 
media is, so they can't provide any hints. It could be just a ringtone, 
or it could be one of those opt-out requests.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2006 12:52:48 -0400

Stephen Sprunk wrote:
> 5. Send/receive RTP according to that 183's SDP (i.e. ignore RTP coming 
> from any other IP/port)
> 7. When a 200 comes in, we ACK it.  If the 200's SDP is different than 
> the PRACKed 183's SDP, switch to the new SDP.

So you leave the other three UASs assuming their 18x has been lost, and 
retransmitting it? If the early media goes on a long time, do you let 
those other legs time out and die?

What do you do if 100rel is not in use?

	Paul

> This seems to work as well as can be expected when forking is used and 
> no other information is available to pick which 183 is "best".  That'd 
> certainly be a nice enhancement, but it's not necessary in the use cases 
> I deal with -- first response seems to work for us.  If others would 
> like to add some sort of indication what type of media a 183 is 
> providing, that may make things easier for other folks.
> 
> S
>

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 18 Jul 2006 22:13:43 +0200

At 20:59 14/07/2006, 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.

Just changing to 200 doesn't alone help -- that should happen along with some
p-charging-fooobar header-field to solve charging problems.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 21 Jul 2006 02:33:38 +0200

At 08:36 19/07/2006, Jeroen van Bemmel wrote:
>Juha,
>
>Sure, it could do that. Drawback is that you could loose other pending branches, if any (and proxy is not instructed otherwise)

I think that's for many a feature. Receiving multiple early media hasnt been real pleasent
consumer experience to me.

>That reminds me - I've wondered if it would be handy to get an indication in a request that it has been forked. This could make a responder aware of such possible consequences, and enable policies like delaying a 2xx answer.

I personally prefer making things simple over introducing new more features that
introduce new patches (to what I perceive a patch already).

-jiri

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 20 Jul 2006 23:34:28 -0500

Thus spake "Paul Kyzivat" <[email-masked]>
>>> Here's a rough outline. I'm sure somebody can do better. The idea  here 
>>> is to do a "media starts" using provisional reliable messages  and a 
>>> "billing starts" using 200 OK.
>>>
>>> I send an INVITE with a new early-media precondition tag. It is  forked 
>>> 4 ways. Each recipient responds with a reliable 18x including
>>> an "early-media request" tag,  possibly including an SDP answer
>>> (for bidirectional or "early session" media), and possibly including
>>> an early-media usage description modifier of some sort.
>>>
>>> I pick one of the 4 responses and send a PRACK with an early-
>>> media - accepted tag. I defer sending PRACK to the other nodes.
>>> Assuming we don't end up moving to a session (with a 200
>>> OK/ACK), somebody CANCELs this leg, and we go on to the next
>>> one.
>>>
>>> CANCEL the remainder, or we time out the prov-rel and they
>>> give up, or we end up CANCELing all of the legs and give up
>>> ourselves, or some combination thereof.
>>>
>>> Crazy, huh?
>>
>> 5. Send/receive RTP according to that 183's SDP (i.e. ignore RTP
>>  coming from any other IP/port)
>> 7. When a 200 comes in, we ACK it.  If the 200's SDP is different
>>  than the PRACKed 183's SDP, switch to the new SDP.
> So you leave the other three UASs assuming their 18x has been
> lost, and retransmitting it? If the early media goes on a long time, do
> you let those other legs time out and die?

Yes and yes.

> What do you do if 100rel is not in use?

All of the cases I've worked with had 100rel, so I'm not sure; I think we'd 
suppress the PRACK but otherwise behave as described above.

I'm not pretending the solution is ideal, but forking and early media are 
fundamentally incompatible so we're doing the best we can.  Perhaps we could 
make a better decision at step 4 if we had more information about what type 
of early media was coming from each leg, but first response is "good enough" 
in most cases, i.e. customers don't complain about how we handle things.

I'll also note that some proxies (but not all, probably about half) that we 
do interop testing with actually insert themselves into the media stream 
during early media, thus we see early media coming from the proxy itself 
(and only a single 183); once one of the legs gets a 200, they will reINVITE 
such that the media is direct between the UAC and UAS.  Since the media 
problem is caused by forking, forcing the proxy that _caused_ the forking to 
deal with the problem seems appropriate, though I'm not sure they're making 
any smarter a decision than we would.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 20 Jul 2006 23:34:28 -0500

Yes and yes.

S

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 21 Jul 2006 14:44:39 +0200

Hi, 

>I'll also note that some proxies (but not all, probably about half)
that we do interop testing with actually insert 
>themselves into the media stream during early media, thus we see early
media coming from the proxy itself (and only a 
>single 183); once one of the legs gets a 200, they will reINVITE such
that the media is direct between the UAC and UAS.  

If a proxy starts initiating re-INVITEs it's not a proxy anymore - it's
a B2BUA, because it will have to deal with the "synchronization" of SDP,
CSeq etc between the UAC and UAS during the whole session.

Regards,

Christer