Subject: [Sipping] Some thoughts on fixing early media

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

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 Jul 2006 10:30:58 -0500

On Jul 13, 2006, at 10:23 AM, Juha Heinanen wrote:

> Dean Willis writes:
> one option is not to "fix" it at all, but simply say that early  
> media is
> not supported by sip.
>

I actually suggested that as my first-choice option during today's  
SIPPING meeting.  We discussed this at some length, with Martin Dolly  
suggesting that he thought he really needed early media. Somebody  
else then pointed out that he didn't really need "early media", he  
just needed the ability to send media from a specific set of UASes  
before starting billing against the UAC under certain conditions.  
This is what I mean by fixing the billing problem, which I think is  
much easier than making early media actually work.

 From a certain point of view, the fix I suggested earlier in this  
thread actually DOES eliminate early media, by transforming all the  
early-media (or "answerless") use cases into proper offer-answer use  
cases that would be less surprising to the UAC. I believe I also  
suggested ways to fix Martin's billing system such that the agreed  
requirements were actually met without allowing early media.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 13 Jul 2006 18:23:51 +0300

> keeps us from fixing things.

one option is not to "fix" it at all, but simply say that early media is
not supported by sip.

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 13 Jul 2006 17:45:07 +0200

Dean,

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

The "best one" response forwarding rule only applies to non-INVITE requests. 
RFC3261 section 16.7 step 5:

Until a final response has been sent on the server transaction,
         the following responses MUST be forwarded immediately:

         -  Any provisional response other than 100 (Trying)

         -  Any 2xx response
[...]

After a final response has been sent on the server transaction,
         the following responses MUST be forwarded immediately:

         -  Any 2xx response to an INVITE request

And if no transaction matches, 2xx responses also MUST be forwarded 
(statelessly).

So the problem with early media and forking may be smaller than you imagined

Regards,

Jeroen

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 13 Jul 2006 12:20:41 -0500

Thus spake "Jeroen van Bemmel" <[email-masked]>
> The "best one" response forwarding rule only applies to non-INVITE 
> requests. RFC3261 section 16.7 step 5:
>

The problems I've run into are slightly different than what Dean describes, 
but they have the same roots.

Imagine someone has set up simultaneous ring, i.e. parallel forking, for 
their number.  The initial invite is forked to two destinations, both of 
which provide early media via 183.  Most servers I've seen in the wild 
forward only the first 183 to the UAC, so the user gets ringback from 
whichever UAS responds quickest.  If one UAS is in the US and another in 
Europe, this results in non-deterministic ringback tones depending on the 
network performance.  Even if the server forwarded both 183s, how would the 
UAC decide which ringback to play to the user?

This gets worse when you consider the number of toll-free numbers than use 
early media to play out their IVR menus and don't "connect" until a human 
answers.  Without bidirectional early media (and several minutes' worth), 
the caller would be unable to get through the menus.  Now combine with sim 
ring and chaos ensues -- which target gets the DTMF digits?  What are the 
effects of that?

I don't see an easy solution to any of this.  Requiring a 200 OK for early 
media doesn't solve the problem, since it's possible every forked 
destination would send a 200 OK in order to send early media and there would 
remain no way to determine which UAS _really_ answered the call.

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: "Francois Audet" <[email-masked]>
Date: Thu, 13 Jul 2006 12:32:47 -0500

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

This would also fix HERFP (which is very similar to early media
forking).

A variant of this would be to deprecate forking-as-we-know-it and
replace it with 302 with multiple contacts with q-values, which would
result in forking being effectively supported by the endpoint itself.

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

Sounds like a non-starter to me.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 13 Jul 2006 20:38:28 +0300

> result in forking being effectively supported by the endpoint itself.

this has been discussed before.  deprecating forking which is in popular
use is completely out of question.  it is MUCH more valuable to
deprecate early media.  it is high time to stop emulating PSTN with
SIP.

-- juha

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 13 Jul 2006 12:44:43 -0500

Dean,

I proposed a "third way" of thinking about this problem. Rather than
approaching it from the viewpoint that the protocol is broken, I think
it's potentially missing a relatively simple control to deal with early
media.

To me, the real problem with forking and early media is that it forces a
decision to be made with too little information. When forking is not
involved, outside of the billing problem (which I think is a separate
problem entirely), there's only one choice so the decision is simple to
execute.

When we have choices in what media should be rendered, then we need some
indication as to the relative importance of each stream we may wish to
render. Essentially, I believe what we need is an early-media-q-value
and early-media-type. The early-media-type would be a description of
what's in the media stream like: operator-announcement ("All Circuits
are busy"), operator-branding ("Thank you for using blah, blah"),
interactive (digit collection), subscriber-service (CRBT, Alert-Info),
and so on. I believe it is likely that there is a reasonably enumerable
set of values. The early-media-q-value would be a relative weight for
the early-media-type to help with tie-breaking between two media
streams.

With this, we should be able to craft a general policy that makes sense
without having to change the underlying protocol behavior.

If people are going to do fraudulent things, they're not going to
respect any part of the protocol. So, trying to massage the SDP in some
way to 'prevent fraud' is not going to be effective. I can simply lie,
send SDP with inactive, or some other shennanigans, and if there's no
gating behavior in the network, exchange media packets with a similarly
hacked client. The permutations of this cat & mouse game are endless,
and is in my estimation a very compelling story for people trying to
bill on protocol messages to cut it out.

Thoughts? If we think that this approach has some legs to it, I'm happy
to write up a document to further discussion.

Regards,
Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 10:17 AM
To: sipping
Subject: [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."

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?

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.

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.

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

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 13 Jul 2006 12:53:10 -0500

Unfortunately, the 302 approach guts the ability to do a lot of things
at the proxy that people want due to timers and such. Plus, there's a
potential privacy issue.

For example, with the approach below, you can't model services like
"ring this number 3 times, then route advance to some other number or
voicemail, etc" because there's a timer and conditional behavior in
there. What you wind up doing is effectively having to send chunks of
CPL like logic back in the 302 to express the behavior that is desired
by the various callee's. It gets worse when you get into recursive
situations where one of the contacts you were redirected to redirects
you, and so on. Not to mention that you'd be exposing the potentially
sensitive routing policy of the person you are calling.

I don't think you want to turn every UA into a proxy that executes CPL
like behavior, or have to manage sending all of the requisite material
around to support such a mechanism.

:(

Regards,
Brian

-----Original Message-----
From: Audet, Francois (SC100:3055) 
Sent: Thursday, July 13, 2006 12:33 PM
To: Dean Willis; sipping
Subject: RE: [Sipping] Some thoughts on fixing early media

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

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

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 13 Jul 2006 12:59:58 -0500

Juha,

Dean clearly explained that deprecating early media ONLY works
if forking is also fixed.

FA> -----Original Message-----
FA> From: Juha Heinanen [mailto:[email-masked]] 
FA> Sent: Thursday, July 13, 2006 10:38 AM
FA> To: Audet, Francois (SC100:3055)
FA> Cc: Dean Willis; sipping
FA> Subject: RE: [Sipping] Some thoughts on fixing early media
FA> 
FA> Francois Audet writes:
FA> 
FA>  > A variant of this would be to deprecate 
FA> forking-as-we-know-it and  > replace it with 302 with 
FA> multiple contacts with q-values, which would  > result in 
FA> forking being effectively supported by the endpoint itself.
FA> 
FA> this has been discussed before.  deprecating forking which 
FA> is in popular use is completely out of question.  it is 
FA> MUCH more valuable to deprecate early media.  it is high 
FA> time to stop emulating PSTN with SIP.
FA> 
FA> -- juha
FA> 
FA>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 13 Jul 2006 13:05:22 -0500

I think this is somewhat orthogonal to Dean's suggestion
of fixing forking by forwarding all responses to the client.

PS: 

To be clear: I prefer Dean's suggestion of forwarding all 
responses to the client than using 302, which limits the 
services that can be done at the proxy, like forwarding
to voicemail and so forth. (We could also do something along
the lines of Rohan's HERFP-fix draft).

FA> -----Original Message-----
FA> From: Stucker, Brian (RICH1:B620) 
FA> Sent: Thursday, July 13, 2006 10:45 AM
FA> To: Dean Willis; sipping
FA> Subject: RE: [Sipping] Some thoughts on fixing early media
FA> 
FA> Dean,
FA> 
FA> I proposed a "third way" of thinking about this problem. 
FA> Rather than approaching it from the viewpoint that the 
FA> protocol is broken, I think it's potentially missing a 
FA> relatively simple control to deal with early media.
FA> 
FA> To me, the real problem with forking and early media is 
FA> that it forces a decision to be made with too little 
FA> information. When forking is not involved, outside of the 
FA> billing problem (which I think is a separate problem 
FA> entirely), there's only one choice so the decision is 
FA> simple to execute.
FA> 
FA> When we have choices in what media should be rendered, then 
FA> we need some indication as to the relative importance of 
FA> each stream we may wish to render. Essentially, I believe 
FA> what we need is an early-media-q-value and 
FA> early-media-type. The early-media-type would be a 
FA> description of what's in the media stream like: 
FA> operator-announcement ("All Circuits are busy"), 
FA> operator-branding ("Thank you for using blah, blah"), 
FA> interactive (digit collection), subscriber-service (CRBT, 
FA> Alert-Info), and so on. I believe it is likely that there 
FA> is a reasonably enumerable set of values. The 
FA> early-media-q-value would be a relative weight for the 
FA> early-media-type to help with tie-breaking between two 
FA> media streams.
FA> 
FA> With this, we should be able to craft a general policy that 
FA> makes sense without having to change the underlying 
FA> protocol behavior.
FA> 
FA> If people are going to do fraudulent things, they're not 
FA> going to respect any part of the protocol. So, trying to 
FA> massage the SDP in some way to 'prevent fraud' is not going 
FA> to be effective. I can simply lie, send SDP with inactive, 
FA> or some other shennanigans, and if there's no gating 
FA> behavior in the network, exchange media packets with a 
FA> similarly hacked client. The permutations of this cat & 
FA> mouse game are endless, and is in my estimation a very 
FA> compelling story for people trying to bill on protocol 
FA> messages to cut it out.
FA> 
FA> Thoughts? If we think that this approach has some legs to 
FA> it, I'm happy to write up a document to further discussion.
FA> 
FA> Regards,
FA> Brian
FA> 
FA> 
FA> 
FA> -----Original Message-----
FA> From: Dean Willis [mailto:[email-masked]]
FA> Sent: Thursday, July 13, 2006 10:17 AM
FA> To: sipping
FA> Subject: [Sipping] Some thoughts on fixing early media
FA> 
FA> 
FA> To recap:
FA> 
FA> Early media entered our vocabulary when we were first 
FA> figuring out PSTN
FA> interworking.
FA> 
FA> Assuming I remember the PSTN terms correctly, in our rather naive
FA> attempt, we mapped  an INVITE to an IAM (Initial Address 
FA> Message), a 180
FA> to an ACM (Address Complete Message), and a 200 OK to an 
FA> ANS (Answer).
FA> 
FA> The problem is, the PSTN often sends one way media from the 
FA> answering
FA> side to the originating side between ACM and ANS. This often happens
FA> with announcement messages from the terminating switch, 
FA> like "The party
FA> you have called is no longer in service."
FA> 
FA> So we said "ok, we'll just require the originator to 
FA> receive and render
FA> media sent to their any of their offered address/port/codec 
FA> entries."
FA> 
FA> Of course, this doesn't work with forking, because you 
FA> might get MANY
FA> streams concurrently, then have to decide how to render them. My
FA> response was to suggest we deprecate forking. But we didn't.
FA> 
FA> And of course the PSTN people latched onto the 200OK as the "please
FA> start billing" request.
FA> 
FA> 
FA> So, now we have a situation where early media always breaks with
FA> forking, often breaks with real network topologies, and can't be
FA> supported right by UAs that have to offer multiple codecs 
FA> but can only
FA> execute one at a time, and the wight of the billing 
FA> mechanism keeps us
FA> from fixing things.
FA> 
FA> 
FA> So how do we fix it?
FA> 
FA> Here's a proposal, building on Rohan's proposal of about 5 
FA> years ago:
FA> 
FA> If a UAS is going to send media, it must first reliably send an SDP
FA> answer (as per offer/answer) in response to the INVITE.  
FA> Typically, we
FA> might expect to see this answer in a 200 OK. This might be 
FA> sendonly if
FA> we're in an early-media situation, and it's reasonable to 
FA> see that SBCs
FA> or MGCF or whatever could enforce the "sendonly"  
FA> modifier to prevent toll fraud. If the call then moves to 
FA> an "answered"
FA> state, we'd re-INVITE to move to bidirectional media. This 
FA> is no more
FA> complicated than the standard mechanism for putting someone 
FA> on-hold, so
FA> it should be quite doable.
FA> 
FA> If this breaks the billing, we just need to fix the billing 
FA> model and
FA> apparatus. Really, it's not our fault. We told the PSTN people many,
FA> many times that billing off of the SIP signaling was unwise. But I
FA> assure you, it would be easier to hack billing start-stop 
FA> functions into
FA> P-headers than to fix early media using a P-header.
FA> 
FA> But what about forking? It's been mentioned that if one 
FA> forks a request
FA> to multiple destinations, and one of those is a PSTN 
FA> gateway, and that
FA> gateway generates ringback using early media, the resulting 
FA> 200 OK will
FA> always cause the forked call to terminate on the PSTN.  
FA> This happens in large part because the forking proxy 
FA> doesn't send all
FA> the responses back to the UAC, just the "best one",  and we 
FA> think 200 OK
FA> is a "pretty good" response to return.
FA> 
FA> I see two possible paths forward:
FA> 
FA> 1) Fix forking so that all responses are forwarded to the 
FA> UAC. I believe
FA> Dale has a draft that suggests exactly this approach. The 
FA> UAC could then
FA> sort out which of many responses it might want to deal 
FA> with, and could
FA> potentially enter media relationships with several UAS 
FA> simultaneously if
FA> needed.
FA> 
FA> 2) Use preconditions. This would result in the PSTN GW doing early-
FA> media placing its offer into a reliable 18x (183 maybe?).  
FA> The forking
FA> proxy could then figure out reasonable processing, 
FA> including possibly
FA> either responding to or delaying the 18x in hopes of 
FA> getting a "real"
FA> 200 OK.
FA> 
FA> Of course, it might also be possible to combine the two approaches.
FA> 
FA> --
FA> Dean
FA> 
FA> _______________________________________________
FA> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
FA> This list is for NEW development of the application of SIP Use
FA> [email-masked] for questions on current sip Use
FA> [email-masked] for new developments of core SIP
FA> 
FA> _______________________________________________
FA> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
FA> This list is for NEW development of the application of SIP
FA> Use [email-masked] for questions on current sip
FA> Use [email-masked] for new developments of core SIP
FA>

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 13 Jul 2006 13:09:34 -0500

I don't. That just pushes the problem further down the chain. At the end
of the day, the client will still need help knowing what it should
render out of the possible choices.

We also can't rely on local policy at the client to do the job,
otherwise network services may not work reliably (or at all) because the
local policy conflicts with the way the service works to prevent the
appropriate media from being rendered.

Regards,
Brian 

-----Original Message-----
From: Audet, Francois (SC100:3055) 
Sent: Thursday, July 13, 2006 1:05 PM
To: Stucker, Brian (RICH1:B620); Dean Willis; sipping
Subject: RE: [Sipping] Some thoughts on fixing early media

I think this is somewhat orthogonal to Dean's suggestion of fixing
forking by forwarding all responses to the client.

PS: 

To be clear: I prefer Dean's suggestion of forwarding all responses to
the client than using 302, which limits the services that can be done at
the proxy, like forwarding to voicemail and so forth. (We could also do
something along the lines of Rohan's HERFP-fix draft).

FA> -----Original Message-----
FA> From: Stucker, Brian (RICH1:B620)
FA> Sent: Thursday, July 13, 2006 10:45 AM
FA> To: Dean Willis; sipping
FA> Subject: RE: [Sipping] Some thoughts on fixing early media
FA> 
FA> Dean,
FA> 
FA> I proposed a "third way" of thinking about this problem. 
FA> Rather than approaching it from the viewpoint that the protocol is 
FA> broken, I think it's potentially missing a relatively simple control

FA> to deal with early media.
FA> 
FA> To me, the real problem with forking and early media is that it 
FA> forces a decision to be made with too little information. When 
FA> forking is not involved, outside of the billing problem (which I 
FA> think is a separate problem entirely), there's only one choice so 
FA> the decision is simple to execute.
FA> 
FA> When we have choices in what media should be rendered, then we need 
FA> some indication as to the relative importance of each stream we may 
FA> wish to render. Essentially, I believe what we need is an 
FA> early-media-q-value and early-media-type. The early-media-type would

FA> be a description of what's in the media stream like:
FA> operator-announcement ("All Circuits are busy"), operator-branding 
FA> ("Thank you for using blah, blah"), interactive (digit collection), 
FA> subscriber-service (CRBT, Alert-Info), and so on. I believe it is 
FA> likely that there is a reasonably enumerable set of values. The 
FA> early-media-q-value would be a relative weight for the 
FA> early-media-type to help with tie-breaking between two media 
FA> streams.
FA> 
FA> With this, we should be able to craft a general policy that makes 
FA> sense without having to change the underlying protocol behavior.
FA> 
FA> If people are going to do fraudulent things, they're not going to 
FA> respect any part of the protocol. So, trying to massage the SDP in 
FA> some way to 'prevent fraud' is not going to be effective. I can 
FA> simply lie, send SDP with inactive, or some other shennanigans, and 
FA> if there's no gating behavior in the network, exchange media packets

FA> with a similarly hacked client. The permutations of this cat & mouse

FA> game are endless, and is in my estimation a very compelling story 
FA> for people trying to bill on protocol messages to cut it out.
FA> 
FA> Thoughts? If we think that this approach has some legs to it, I'm 
FA> happy to write up a document to further discussion.
FA> 
FA> Regards,
FA> Brian
FA> 
FA> 
FA> 
FA> -----Original Message-----
FA> From: Dean Willis [mailto:[email-masked]]
FA> Sent: Thursday, July 13, 2006 10:17 AM
FA> To: sipping
FA> Subject: [Sipping] Some thoughts on fixing early media
FA> 
FA> 
FA> To recap:
FA> 
FA> Early media entered our vocabulary when we were first figuring out 
FA> PSTN interworking.
FA> 
FA> Assuming I remember the PSTN terms correctly, in our rather naive 
FA> attempt, we mapped  an INVITE to an IAM (Initial Address Message), a

FA> 180 to an ACM (Address Complete Message), and a 200 OK to an ANS 
FA> (Answer).
FA> 
FA> The problem is, the PSTN often sends one way media from the 
FA> answering side to the originating side between ACM and ANS. This 
FA> often happens with announcement messages from the terminating 
FA> switch, like "The party you have called is no longer in service."
FA> 
FA> So we said "ok, we'll just require the originator to receive and 
FA> render media sent to their any of their offered address/port/codec 
FA> entries."
FA> 
FA> Of course, this doesn't work with forking, because you might get 
FA> MANY streams concurrently, then have to decide how to render them. 
FA> My response was to suggest we deprecate forking. But we didn't.
FA> 
FA> And of course the PSTN people latched onto the 200OK as the "please 
FA> start billing" request.
FA> 
FA> 
FA> So, now we have a situation where early media always breaks with 
FA> forking, often breaks with real network topologies, and can't be 
FA> supported right by UAs that have to offer multiple codecs but can 
FA> only execute one at a time, and the wight of the billing mechanism 
FA> keeps us from fixing things.
FA> 
FA> 
FA> So how do we fix it?
FA> 
FA> Here's a proposal, building on Rohan's proposal of about 5 years 
FA> ago:
FA> 
FA> If a UAS is going to send media, it must first reliably send an SDP 
FA> answer (as per offer/answer) in response to the INVITE.
FA> Typically, we
FA> might expect to see this answer in a 200 OK. This might be sendonly 
FA> if we're in an early-media situation, and it's reasonable to see 
FA> that SBCs or MGCF or whatever could enforce the "sendonly"
FA> modifier to prevent toll fraud. If the call then moves to an 
FA> "answered"
FA> state, we'd re-INVITE to move to bidirectional media. This is no 
FA> more complicated than the standard mechanism for putting someone 
FA> on-hold, so it should be quite doable.
FA> 
FA> If this breaks the billing, we just need to fix the billing model 
FA> and apparatus. Really, it's not our fault. We told the PSTN people 
FA> many, many times that billing off of the SIP signaling was unwise. 
FA> But I assure you, it would be easier to hack billing start-stop 
FA> functions into P-headers than to fix early media using a P-header.
FA> 
FA> But what about forking? It's been mentioned that if one forks a 
FA> request to multiple destinations, and one of those is a PSTN 
FA> gateway, and that gateway generates ringback using early media, the 
FA> resulting 200 OK will always cause the forked call to terminate on 
FA> the PSTN.
FA> This happens in large part because the forking proxy doesn't send 
FA> all the responses back to the UAC, just the "best one",  and we 
FA> think 200 OK is a "pretty good" response to return.
FA> 
FA> I see two possible paths forward:
FA> 
FA> 1) Fix forking so that all responses are forwarded to the UAC. I 
FA> believe Dale has a draft that suggests exactly this approach. The 
FA> UAC could then sort out which of many responses it might want to 
FA> deal with, and could potentially enter media relationships with 
FA> several UAS simultaneously if needed.
FA> 
FA> 2) Use preconditions. This would result in the PSTN GW doing early- 
FA> media placing its offer into a reliable 18x (183 maybe?).
FA> The forking
FA> proxy could then figure out reasonable processing, including 
FA> possibly either responding to or delaying the 18x in hopes of 
FA> getting a "real"
FA> 200 OK.
FA> 
FA> Of course, it might also be possible to combine the two approaches.
FA> 
FA> --
FA> Dean
FA> 
FA> _______________________________________________
FA> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
FA> This list is for NEW development of the application of SIP Use 
FA> [email-masked] for questions on current sip Use 
FA> [email-masked] for new developments of core SIP
FA> 
FA> _______________________________________________
FA> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
FA> This list is for NEW development of the application of SIP Use 
FA> [email-masked] for questions on current sip Use 
FA> [email-masked] for new developments of core SIP
FA>

---

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

On Jul 13, 2006, at 12:20 PM, Stephen Sprunk wrote:

>
> I don't see an easy solution to any of this.  Requiring a 200 OK  
> for early media doesn't solve the problem, since it's possible  
> every forked destination would send a 200 OK in order to send early  
> media and there would remain no way to determine which UAS _really_  
> answered the call.
>

But at least multiple answers would provide a clear mechanism by  
which the forking proxy could detect that it had caused a problem and  
start trying cleanup measures.

The real problem we have now is that we have a problem that can  
really only be detected by the bad experience of the end user.

--
Dean

---

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

Thus spake "Dean Willis" <[email-masked]>
>> I don't see an easy solution to any of this.  Requiring a 200 OK  for 
>> early media doesn't solve the problem, since it's possible  every forked 
>> destination would send a 200 OK in order to send early  media and there 
>> would remain no way to determine which UAS _really_  answered the call.
>
> But at least multiple answers would provide a clear mechanism by  which 
> the forking proxy could detect that it had caused a problem and  start 
> trying cleanup measures.
>
> The real problem we have now is that we have a problem that can  really 
> only be detected by the bad experience of the end user.

On the contrary, today the proxy and UAC can tell there's a problem when two 
183s are received, whereas with your change only the proxy will know (if it 
consumes the second 200) or there would be no change (if the proxy forwards 
the second 200).  I see no improvement.  The situation is fundamentally 
broken due to the forking, and changing the present behavior just moves the 
problem to a different place.

S

---

From: Darshan Bildikar <[email-masked]>
Date: Fri, 14 Jul 2006 10:14:47 +0530

I've seen it mentioned many times on the SIPPING list that charging based on
SIP signaling is a bad idea.

Two questions

1) Why is it a bad idea?
2) What is the suggested alternative to charging SIP services if not based
on signaling?

Sorry if my question is too basic but I'd appreciate any pointers in the
right direction.

BR
Darshan

---

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

>much easier than making early media actually work.

I absolutely agree with that. There is a documentable history of all kinds 
of troubles with early media and there has been, as we see, no end to it. 
Basically solving a charging issue by twisting the transaction model turned 
out to be a real inpractical solution in many cases (including charging too, 
forking/early-media to name one very specific trouble at the risk that
some individuals will suggest deprecation of forking too :-))). The
suggestion from the floor to depracate early media and address charging
issues by some p-charging header fields sounds workable to me.

The question to me then is how we could best migrate to the non-early-media
version.

-jiri

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

---

From: David R Oran <[email-masked]>
Date: Fri, 14 Jul 2006 10:35:11 -0400

> SIP signaling is a bad idea.
Because you have no idea what is going on in the media plane based on  
what is happening with the signaling. If you want to charge me $.001  
per SIP transactions that's fine, but what people are trying to do is:
a) bill for the media based on the state machines in the signaling, and
b) bill for the duration of a session where the actual resource usage  
is independent of that (as opposed to the situation in the TDM/ 
circuit-switched world).

Both of these are deeply flawed ideas inherited without scrutiny from  
the PSTN world.

> 2) What is the suggested alternative to charging SIP services if  
1) Have the routers bill for the media carriage.
2) Have the routers or policy servers bill based on the installation/ 
remmoval of traffic classifiers and associated resource reservations  
in the routers.

Dave Oran.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 14 Jul 2006 10:48:34 -0400

> SIP signaling is a bad idea.

More specifically, it is a bad idea to try to bill for _minutes_ via  
signaling.

There are two basic reasons. First, since signaling and media are  
decoupled, it is possible for UAs to play games with you. For  
example, they might setup a call and immediately tear it down  
immediately, but continue sending media.  You can stop this in the  
network if you control the media path, but that requires putting more  
complexity (read: more money and more things to go wrong and get in  
the way of new services.) in the network.

The second is that charging on signaling often creates inequitable  
billing. For example, the UAs may send signaling through your  
network, but discover through ICE or something that they have a more  
optimal media path that does not cross your network _at_all_. If you  
bill on signaling, you will likely bill them for a service you did  
not actually provide to them.

> 2) What is the suggested alternative to charging SIP services if  

I don't think there is consensus on this. My personal thoughts are  
that you bill based on whatever scarce resource you provide.

For example, you might not carry media at all, but you do provide SIP  
rendez-vouz services. In this case, it might make sense to bill based  
on sip register requests or location service lookups. Unfortunately,  
this does not match the legacy business models of most providers--but  
there is no reason a _new_ provider (or a forward looking one) could  
not select this approach. There are probably regulatory issues  
depending on where you are and what kind of provider you are.

Another scarce resource could be port-minutes at a PSTN gateway.  
Since the gateway would be a media endpoint, then you can bill based  
on actual media use, in terms of minutes that the port is active,  
bytes, etc. To generalize this, if you own at least one end of the  
_media_ session, you can bill on that.

A completely different approach would be to do what IMS does, which  
is to tie routing policy for the media path to the SIP signaling.  
Basically, they tightly control the media path, block media if they  
don't think a session should be open, and put additional P-headers in  
the signaling for request correlation. This falls into the class of  
adding complexity to the network, I mention above :-)

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Fri, 14 Jul 2006 11:33:52 -0500

You all need to have an understanding of the contractual agreement
between the subscriber and the carrier, before having an opinion on this
topic

---

From: Harry Behrens <[email-masked]>
Date: Fri, 14 Jul 2006 19:08:52 +0200

I couldn't agree more.

SIP's main field of application has moved from academia to
telecommunications.

telecommunications needs to deal with SLAs, pricing, billing, legal
intercept etc.

a more pragmatic approach, which orients itself on what is rather than
what could/should be,  would surely be helpful.

just my 2c,

Harry

Dolly, Martin C, ALABS wrote:

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Friday, July 14, 2006 10:49 AM
To: [email-masked]
Cc: 'sipping'
Subject: Re: [Sipping] Newbie Question

I've seen it mentioned many times on the SIPPING list that charging
based on
SIP signaling is a bad idea.

Two questions

1) Why is it a bad idea?

2) What is the suggested alternative to charging SIP services if
not based
on signaling?

Sorry if my question is too basic but I'd appreciate any pointers
in the
right direction.

BR
Darshan

---

From: Ben Campbell <[email-masked]>
Date: Fri, 14 Jul 2006 14:28:01 -0400

Certainly. That is why I mentioned these may be issues with existing  
providers, and that regulatory issues may come into play.

---

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

On Jul 13, 2006, at 11:22 PM, Stephen Sprunk wrote:

>>> every forked destination would send a 200 OK in order to send  
>>> early  media and there would remain no way to determine which UAS  
>>> _really_  answered the call.
>>
>> which the forking proxy could detect that it had caused a problem  
>> and  start trying cleanup measures.
>>
> On the contrary, today the proxy and UAC can tell there's a problem  
> when two 183s are received, whereas with your change only the proxy  
> will know (if it consumes the second 200) or there would be no  
> change (if the proxy forwards the second 200).  I see no  
> improvement.  The situation is fundamentally broken due to the  
> forking, and changing the present behavior just moves the problem  
> to a different place.

Two 183s does NOT, as far as I know, mean you have a problem. Nor  
does two 180s. The problem occurs when two media streams show up at  
the UAS concurrently.

So the trick is to prevent two media streams from showing up at the  
same time.

One way to do this is by moving to a two-stage-commit model.  Stage 1  
is "offer/answer". Stage 2 is "media flowing". The UAC has to handle  
acceptance of  a transition to stage two so that it doesn't get into  
that stage with two or more partners at the same time unless it can  
handle it. This requires some sort sort of positive acknowledgment,  
after the offer/answer completes, from UAC to UAS before UAS can send  
media. One way to achieve this would be the use of preconditions. The  
O/A completes in the preconditions cycle, and the condition being  
satisfied is essentially "UAC is ready for media".

Another model is to simply preclude transmission of media from UAS to  
UAC until the UAS receives an ACK. Yeah, this clips "Hello". But it  
gives the UAC (or forking proxy)  who may have received multiple 200  
OK messages the option to pick which response it's going to process  
media (and ACK) on. In the case of a UAS handling it, the UAS would  
simply defer ACKs to serialize the media streams. In the case of a  
forking proxy handling it, the FP would delay 200 OK responses so  
that that only one media session would be visible to the UAS at any  
given time. We'd still need a prioritization policy, but at least it  
makes the problem tractable from a signaling perspective.

Of course, the whole problem just goes away if instead of SIP's  
INVITE/200 OK/ACK model we were to follow Cullen's suggested "OFFER/ 
200OK, ANSWER/200OK" sequence.

I have another proposal I like better, but I'm not allowed to suggest  
it anymore.

--
Dean

---

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

Here's a typical case:

Service Provider X wanted to do SIP telephony services. They didn't  
provide any network transport. Customers brought their own ISP  
connections to the table.  All Provider X did was handle the  
rendezvous function -- accepting REGISTER requests and routing INVITE  
requests accordingly.

Provider X wanted to bill by the minute (at a fairly hefty rate, too)  
for calls set up this way. In my opinion, they were trying to charge  
for a service (minutes of RTP session) that they weren't providing  
and that the customer s were already paying some other ISP for.

Provider X was horrified when after a few days of operation, a  
modified User Agent showed up that sent Bye/200 OK sequences 1 second  
after INVITE/200OK/ACK sequences, but that didn't actually tear down  
the RTP session. Instead, it utilized user input to decide when to  
end its RTP sessions. Oddly enough, this was the original design  
model of SIP -- the BYE transaction was added fairly late in the  
design, resulting in (or perhaps reflecting) a schism between the  
authors that caused them to pursue separate paths going forward.

The ethical question: Who was stealing from whom here? Provider X,  
the ISPs, or the users?

--
Dean

---

From: Harry Behrens <[email-masked]>
Date: Tue, 18 Jul 2006 14:25:14 +0200

The ethical question: Who was stealing from whom here? Provider X,  the
ISPs, or the users?

ethics in my opinion is a hard topic to discuss in a technical forum.

shouldn't we rather focus on real and present requirements and business
processes which ultimately own and drive the technology being discussed
here?

just trying to keep the eye on the ball...

Harry

--

Dean

You all need to have an understanding of the
contractual agreement

between the subscriber and the carrier, before having an opinion on
this

topic

-----Original Message-----

To: [email-masked]

Cc: 'sipping'

based on

Two questions

1) Why is it a bad idea?

signaling.

2) What is the suggested alternative to
charging SIP services if

not based

on signaling?

there is no reason a _new_
provider (or a forward looking one) could

in the

right direction.

BR

Darshan

Use [email-masked]
for questions on current sip

Use [email-masked]
for new developments of core SIP

Use [email-masked]
for questions on current sip

Use [email-masked]
for new developments of core SIP

Use [email-masked]
for questions on current sip

Use [email-masked]
for new developments of core SIP

Use [email-masked]
for questions on current sip

Use [email-masked]
for new developments of core SIP

---

From: Harry Behrens <[email-masked]>
Date: Tue, 18 Jul 2006 13:43:39 +0200

Harry

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 21 Jul 2006 12:00:35 -0500

What if we used the following model:

1. UAC sends INVITE (no SDP) just to get the routing settled and the
forking started.
2. UAS sends an offer back in either a reliable-183 (yuck) or an UPDATE
(nicer).
3. UAC responds with an answer using the sendrecv parms to indicate if
it is interested in having media flow (just like hold/retrieve flows).
3a. If the UAC doesn't want media yet, it can send an answer back with
a=inactive.
3b. If the UAC does want media now, it can send an answer back with
a=sendrecv.
4. The UAC, upon deciding that it's ready for the media stream, can send
an updated offer with the sendrecv parm set appropriately.

Without pre-conditions working with this, there's a risk that the far
end will alert and you could get severe clipping because a previously
early media stream is on hold because the UAC was staging that stream. I
don't think you can reuse the existing binary preconditions settings to
safely get around this and the original intent of preconditions, so
probably an early-media staging version of preconditions could be used
here to denote "don't send me any early media until I ask for it, but if
the UAS answers, the UAC will accept media immediately from that
endpoint".

Thoughts?

Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Monday, July 17, 2006 5:07 PM
To: Stephen Sprunk
Cc: sipping
Subject: Re: [Sipping] Some thoughts on fixing early media

> will know (if it consumes the second 200) or there would be no change 
> (if the proxy forwards the second 200).  I see no improvement.  The 
> situation is fundamentally broken due to the forking, and changing the

> present behavior just moves the problem to a different place.

Two 183s does NOT, as far as I know, mean you have a problem. Nor does
two 180s. The problem occurs when two media streams show up at the UAS
concurrently.

So the trick is to prevent two media streams from showing up at the same
time.

One way to do this is by moving to a two-stage-commit model.  Stage 1 is
"offer/answer". Stage 2 is "media flowing". The UAC has to handle
acceptance of  a transition to stage two so that it doesn't get into
that stage with two or more partners at the same time unless it can
handle it. This requires some sort sort of positive acknowledgment,
after the offer/answer completes, from UAC to UAS before UAS can send
media. One way to achieve this would be the use of preconditions. The
O/A completes in the preconditions cycle, and the condition being
satisfied is essentially "UAC is ready for media".

Another model is to simply preclude transmission of media from UAS to
UAC until the UAS receives an ACK. Yeah, this clips "Hello". But it
gives the UAC (or forking proxy)  who may have received multiple 200 OK
messages the option to pick which response it's going to process media
(and ACK) on. In the case of a UAS handling it, the UAS would simply
defer ACKs to serialize the media streams. In the case of a forking
proxy handling it, the FP would delay 200 OK responses so that that only
one media session would be visible to the UAS at any given time. We'd
still need a prioritization policy, but at least it makes the problem
tractable from a signaling perspective.

I have another proposal I like better, but I'm not allowed to suggest it
anymore.

--
Dean