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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 13 Jul 2006 14:12:30 -0400

So which announcement takes precedence?:

"Thank-you for calling pay-per-second, if you continue the cost is...
if you don't want to pay please hang up now."

"We are required by regulations to tell you that this call destination
is... if this upsets you please hang up now."

It seems to be if you have already adequately categorized the message,
the in-band message itself is no longer needed for the UAC (or proxy) to
make a decision as to which call to send through and which to cancel.
At that point it seems like you have just eliminated early media
altogether.

Mike

> -----Original Message-----
> From: Brian Stucker [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 1:45 PM
> To: Dean Willis; sipping
> Subject: RE: [Sipping] Some thoughts on fixing early media
> 
> 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."
> 
> 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
> 

_______________________________________________
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 13:23:22 -0500

They could be ordered, a choice isn't necessarily forced. If your first
option has an early-media-q-value that is higher than the second one,
then you render them in that order.

I'm not saying that there are cases that can be composed that make the
decision tough to execute. What I am saying is that such a mechanism is
likely to cover off on a wide variety of cases of interest that are
currently much more difficult to deal with due to lack of information.
To use your example, today, I'd likely miss your pay-per-second
announcement if another service like CRBT were enabled which is
obviously worse.

I also was not intending this mechanism to be used for which leg to
cancel or send through. This would be information that a client or other
element could use to know what the other end expects of them for the
purposes of rendering the early media. It's not eliminating it, because
this is all still occurring prior to the 200 OK, nor is it necessarily
pruning the tree (although that's probably what will happen in the vast
number of cases).

Regards,
Brian 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 1:13 PM
To: Stucker, Brian (RICH1:B620); Dean Willis; sipping
Subject: RE: [Sipping] Some thoughts on fixing early media

Mike

> 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 
> 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 
> 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
> 
> 
> 
> Early media entered our vocabulary when we were first figuring out 
> PSTN interworking.
> 
> 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).
> 
> 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."
> 

> we're in an early-media situation, and it's reasonable to see that 
> SBCs or MGCF or whatever could enforce the "sendonly"
> complicated than the standard mechanism for putting someone on-hold, 
> so it should be quite doable.
> 
> 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.
> 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.
>