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

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

An added thought.

If you can categorize the early media types, it should primarily focus
on:
1) enough information for the proxy or UAC to eliminate selected calls
from consideration,
2) for survivors, provides information that there is an in-band message
to be sent (but not until permitted), 
3) a mechanism for the UAC/proxy to play red-light, green-light with all
the UAS so that only one inband message is sent at a time to the UAC,
which has two effects:
   a) the UAC doesn't have to guess which of N simultaneous media to
play,
   b) the UAC has an easier time correlating which media goes with which
UAS.

Mike

> -----Original Message-----
> From: Brian Stucker [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 2:10 PM
> To: Francois Audet; Dean Willis; sipping
> Subject: RE: [Sipping] Some thoughts on fixing early media
> 
> 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> 
> 
> _______________________________________________
> 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:57:33 -0500

Agreed, number 3 in particular is going to be necessary in certain
situations.

Regards,
Brian 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 1:26 PM
To: Stucker, Brian (RICH1:B620); Audet, Francois (SC100:3055); Dean
Willis; sipping

An added thought.

Mike

> 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
> 
> 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).
> 
> 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: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jul 2006 15:53:58 -0400

IMO using categorization as a solution is a non-starter. The primary use 
case is when talking to a gateway, which itself has no idea whether the 
media it is providing is just ringback, a message, a prompt, or whatever.

When the category is known it is is also probably possible to use the 
application server (early-session) approach, which deals with most of 
these situations.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 13 Jul 2006 16:30:29 -0500

Saying that there's a set of usecases that we can't solve (with any
mechanism) means that we shouldn't solve any that remain seems
self-defeating. 

There are a number of usecases that are deployed to the field that do
not involve PSTN gateway supplied media that run amok of early media
interactions. As more and more of the PSTN is converted to SIP this is
only going to increase, this is already happening.

You always need to know what to render at the end of the day because
it's all going into one speaker at the end of the wire. I also don't
think having some anonymous box in the middle of the network making a
unilateral decision as to what will get rendered is always desirable.

I went back to 3959 and don't see where you are going with early-session
and how that would fix the rendering problem. Can you elaborate?

Regards,
Brian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 2:54 PM
To: Michael Hammer (mhammer)
Cc: Stucker, Brian (RICH1:B620); Audet, Francois (SC100:3055); Dean
Willis; sipping
Subject: Re: [Sipping] Some thoughts on fixing early media

IMO using categorization as a solution is a non-starter. The primary use
case is when talking to a gateway, which itself has no idea whether the
media it is providing is just ringback, a message, a prompt, or
whatever.

	Paul

> from consideration,
> 2) for survivors, provides information that there is an in-band 
> message to be sent (but not until permitted),
> 3) a mechanism for the UAC/proxy to play red-light, green-light with 
> all the UAS so that only one inband message is sent at a time to the 
> UAC, which has two effects:
>    b) the UAC has an easier time correlating which media goes with 
> which UAS.
> 
> Mike
> 
> 
> 
>> At the end of the day, the client will still need help knowing what 
>> it should render out of the possible choices.
>>
>> all) because the local policy conflicts with the way the service 
>> works to prevent the appropriate media from being rendered.
>>
>> Regards,
>> Brian
>>
>> 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).
>>