Subject: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?]

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Mar 2010 21:57:59 +0100

Hi,

I thought we already had the annual thread on solving early media, but I guess it doesn't hurt to discuss it a little more often ;)

>>Serial forking with early media depends on support for PRACK and  UPDATE, which are not mandatory items for UAs and therefore will not always be available.
>
>As always, I think early media was just a really bad idea. But we always dance away from trying to fix the problem.
>
>>I would like to expand on this issue a little. Suppose I have at my
>>home proxy a policy whereby calls go to B1 and B2 in parallel, and
>>after T seconds of no answer calls instead go to B3 (voicemail,
>>perhaps). There is no way that the proxy could convey that policy in
>>a 3xx response to the UAC. To make this policy (or similar policies)
>>work, the proxy would need to manufacturer temporary contact URIs
>>that map to B1 and B2 and send these back in a 302. It would then
>>need to hope that the UAC does indeed establish new requests in
>>parallel to the two temporary contacts for B1 and B2. The proxy
>>would need to treat the two requests as related and if both are
>>unanswered after T seconds, reject one with a 4xx and the other with
>>a 302 (this time with a third temporary contact URI mapped to B3).
>>So policy CAN be met by the proxy, although with dependence on the
>>UAC doing the right thing.
>
>So here, we either need your home proxy to be a home B2BUA (After all,
>what happens when B1 and B2 both send back early media, or both get
>answered by a bot?), OR we need a richer 302 response that conveys
>"Try these two destinations in parallel, and if neither replies in X
>seconds, try this third destination).

But, the UAC still doesn't know whether B1 and B2 would send early media.

>Either is tractable. Admittedly, the second requires extending the
>specification of a 302 response, but we have the capacity to do this.
>A few standardized parameters would work fine, with no backward
>compatibility issues for  older nodes that don't understand the
>parameters. Much could be done with q-values.

Much could also have been done by alloing P-Early-Media:inactive in the INVITE request, and then
indicating to the UAC for which early dialog early media has been "allowed". The UAC can then change
that by sending a PRACK/UPDATE

Also, there could be a feature tag which UAS(s) use during registration to indicate whether they support sending of early media or not.

I don't think that SIP UAs will send early media that often. PSTN gateways can do it. 

Appplication servers can also do it, but they are most likely located "in front of" the forking proxy. And, if they would send a 3xx response, the 3xx from the forking proxy would most likely be rejected by the UAC (since it already received a final response from the AS). So, the application servers could instead create a separate early dialog with the UAC, but that early dialog (and possible announcements etc that goes with it) would then be terminated in an unwanted manner by the 3xx from the forking proxy.

>> Elsewhere in this thread, somebody mentioned charging. The fact is
>> that calls might cross a domain that charges (e.g., for
>> international calls via a server provider into an enterprise that
>> has a proxy that makes use of 302 responses to achieve forking).
>> Since only one of the calls should normally be answered (or if a
>> second is answered it should be cleared very quickly), charging
>> based on duration after answer should not be a big issue. However,
>> if a domain charges for call establishment attempts, it could be a
>> problem. In this example, the domain handling the international leg
>> would not be aware that the multiple calls are really part of the
>> same call. I don't know whether this is an issue in practice or not.
>
>The real question is "who gets charged, and are they surprised by it?"
>
>If the "home proxy" is forwarding the call to a toll destination, then
>either the "home proxy" needs to get charged for the toll (making it
>more B2BUA is), or the originating user needs to get charged for it,
>in which case the originating user needs to know about the toll
>destination (requiring a 302).

That assumes that the forking proxy has information about whether a contact is associated with a toll number, and that the calling device is able to present that information to the caller.

There is a service called Advice Of Charge. I believe it contains a feature to not allow certain calls to take place if the calling user can't be informed about it, but I don't remember the details.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Fri, 5 Mar 2010 15:19:33 -0600

> But, the UAC still doesn't know whether B1 and B2 would send early  

By offering different ports to B1 and B2 (especially with the media-to- 
signaling coupling extensions that have been proposed) UAC at least  
knows which one of B1 and B2 each stream is coming from.

--
dean

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Mar 2010 23:36:02 +0100

Hi,

>By offering different ports to B1 and B2 (especially with the media-to-signaling coupling extensions that have been proposed) UAC at least knows which one of B1 and B2 each stream is coming from.

Yes. But, there are other mechanisms to solve that, and it still doesn't solve the fundamental problem: the UAC can receive multiple media streams associated with multiple early dialogs.

Also, in bandwidth sensitive access networks there is only limited bandwidth, normally calculated based on the need for media associated with one early dialog. Even if the UAC is able to select and play only one stream to the user, the voice quality will suffer due to too little bandwidth.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Mar 2010 18:04:13 -0500

If you want parallel forking, even if done by the UAC, there is no good 
solution to this problem. The parallel early media is going to be 
generated and something must happen to it. The only question is which of 
the bad solutions you prefer.

For instance, you may have one stream asking you to enter an access 
code, another playing an out-of-service tone, and a third sending no 
media which will eventually pick up with a real person. What would you 
*like* for the caller to hear?

	Thanks,
	Paul

Christer Holmberg wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 6 Mar 2010 00:15:47 +0100

Hi,

>If you want parallel forking, even if done by the UAC, there is no good solution to this problem. The parallel early media is going to be generated and something must happen to it. The only question is 
>which of the bad solutions you prefer.
>
>For instance, you may have one stream asking you to enter an access code, another playing an out-of-service tone, and a third sending no media which will eventually pick up with a real person. What would 
>you *like* for the caller to hear?

For this reasons you have B2BUAs, application servers, gating nodes etc, that at least TRY to deal with the problem, to ensure that whatever the user eventually hears, at least the quality will be good.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Mar 2010 18:30:27 -0500

> For this reasons you have B2BUAs, application servers, gating nodes etc, that at least TRY to deal with the problem, to ensure that whatever the user eventually hears, at least the quality will be…

For what that's worth! You get a good quality rendering of that 
out-of-service tone, and so hang up even though the call was ringing 
elsewhere, but without any ringback.

I guess we just have to "let a 1000 flowers bloom" on this one.

	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 6 Mar 2010 10:10:09 +0100

Hi,

>>>If you want parallel forking, even if done by the UAC, there is no good solution to this problem. The 
>>>parallel early media is going to be generated and something must happen to it. The only question is
>>>For instance, you may have one stream asking you to enter an access code, another playing an out-of-
>>>service tone, and a third sending no media which will eventually pick up with a real person. What would
>>For this reasons you have B2BUAs, application servers, gating nodes etc, that at least TRY to deal with the 
>>problem, to ensure that whatever the user eventually hears, at least the quality will be good.
>

As I've said before, I don't think there is a very big risk that the "wrong" early media would be presented to you.

Leaving PSTN interworking aside, most early media (at least the one of real importance) will be generated by application servers/B2BUAs in the network, and they will normally be able to control the media pretty well. A SIP UA might generate something, but unless it's a Henry Sinnreich device (where all the services are implemented in the end device :) I don't think UAs will normally send service related announcement etc.

Of course, if you have application servers sending media both in the originating and terminating network, there need to be some policy procedures on which media has higher priority etc.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Sat, 6 Mar 2010 12:13:15 -0600

On Mar 5, 2010, at 5:04 PM, Paul Kyzivat wrote:

> If you want parallel forking, even if done by the UAC, there is no  
> good solution to this problem. The parallel early media is going to  
> be generated and something must happen to it. The only question is  
> media which will eventually pick up with a real person. What would  

I at least want the caller to be able to correlate a media flow with a  
signaling leg so they know which one is which.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Mar 2010 11:47:34 -0500

> Leaving PSTN interworking aside, most early media (at least the one of real importance) will be generated by application servers/B2BUAs in the network, and they will normally be able to control the…

I gather you are arguing that there just aren't many calls with early 
media. But "leaving PSTN interworking aside" isn't really fair, since 
there is so much of that. For instance there could be a lot of the 
google service that simply forks calls to multiple PSTN lines. And don't 
most pstn calls have in-band ringback? That would get multiple early 
media, though if its just ringback it doesn't matter if you play it or 
not. But if one of those becomes defective and starts playing out of 
service messages then it does matter which one you play.

> Of course, if you have application servers sending media both in the originating and terminating network, there need to be some policy procedures on which media has higher priority etc.

Policy doesn't help a lot. It content, not policy, that determines which 
is important to hear.

Perhaps the best we can do is discourage the use of early media for 
anything important.

	Thanks,
	Paul

---

From: "Gilad Shaham" <[email-masked]>
Date: Sun, 7 Mar 2010 23:41:07 +0200

> Perhaps the best we can do is discourage the use of early media for

I'm not sure this scenario is that common, but if it is something of
interest, perhaps it's possible to add a header/parameter conveying the
nature of the media stream (ringback, service message, voice, etc.). This is
similar to the content-disposition handling parameter, but more informative
than "optional" and "required". This way, a B2BUA would be able to choose
the stream to forward and even without a B2BUA, an endpoint receiving
several streams would know which stream to play back to the user.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Mar 2010 09:37:52 -0500

> several streams would know which stream to play back to the user.

I guess this would be something like the Reason header, or maybe it 
would really be the Reason header, though it would take some changes to 
allow it for that. Another possibility for this is Alert-Info.

The response code, possibly augmented with the Reason header, would work 
for things like out of service that are going to cause the call to fail. 
However the callee has to have confidence that the caller will be 
properly informed of the case.

The Alert-Info containing a URN can potentially work for common things 
that aren't going to cause the call to fail. But that isn't sufficient 
if there is variable information to convey to the caller, unless it is 
done with with a URI that can be dereferenced and rendered. The latter 
would be an alternative if we could convince UAs to render such things. 
My impression is that there is reluctance to do so, though it really 
isn't much different from rendering an early media string.

But none of this will help with many pstn interop cases where the reason 
isn't known except through the content of the media.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 8 Mar 2010 09:44:44 -0600

On Mar 8, 2010, at 8:37 AM, Paul Kyzivat wrote:

> would really be the Reason header, though it would take some changes  
> to allow it for that. Another possibility for this is Alert-Info.

Nut at the moment, we have UAs sending back media that have sent no  
SIP messages yet. So there's no place to add a  Reason header.

The only thing that's under the UAC's control is the offer, and AFAIK  
the only thing the UAC can do to differentiate early media streams is  
somehow assure that a different offer (with a different listening  
port) is used for each offer. The UAC cannot do this if the offer is  
forked by a proxy.

> ...

> But none of this will help with many pstn interop cases where the  
> reason isn't known except through the content of the media.

And even worse: assuming that the UAC has the ability to play-out all  
the potentially interesting media streams, there's no way for the UAC  
or the user thereof to CANCEL any leg and thereby "stop" early media  
with today's model. That's because one offer is used for all the early- 
media.

So for a UA that's really smart and can do some level of analysis  
within the media path (like say "Press 1 if you want to accept this  
call" and then wait for a tone, or perhaps do speech-recognition),  
there's still no ability for it to clean up the early media by  
signaling until the early media becomes a regular media session.

People claim to be worried about the media bandwidth impact of doing a  
302 back to the UA and having it do the forking, but the simple fact  
is that at least in this scenario the UA can control the result,  
whereas with proxy parallel forking, the UA potentially gets hammered  
with multiple parallel early media streams and has no way to do  
anything about it.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Mar 2010 12:20:26 -0500

Dean Willis wrote:
> Nut at the moment, we have UAs sending back media that have sent no SIP 
> messages yet. So there's no place to add a  Reason header.

I wasn't thinking of discriminating the early media streams, but rather 
finding ways to eliminate them while retaining their intent.

> somehow assure that a different offer (with a different listening port) 
> is used for each offer. The UAC cannot do this if the offer is forked by 
> a proxy.
> 
>> ...
> 
> the potentially interesting media streams, there's no way for the UAC or 
> the user thereof to CANCEL any leg and thereby "stop" early media with 
> today's model. That's because one offer is used for all the early-media.

Several years ago Rohan proposed a model where the UAC did another O/A 
with each early dialog to move its media to a distinct port. That way it 
could then associate the signaling with a particular media stream. Seems 
cumbersome, but maybe it will take something like that to solve the problem.

> So for a UA that's really smart and can do some level of analysis within 
> the media path (like say "Press 1 if you want to accept this call" and 
> then wait for a tone, or perhaps do speech-recognition), there's still 
> no ability for it to clean up the early media by signaling until the 
> early media becomes a regular media session.
> 
> 302 back to the UA and having it do the forking, but the simple fact is 
> that at least in this scenario the UA can control the result, whereas 
> with proxy parallel forking, the UA potentially gets hammered with 
> multiple parallel early media streams and has no way to do anything 
> about it.

Yes. The cost and difficulty of the UAC handling the forking seems no 
worse that the extra O/As I mention above.

But even if you have each early dialog associated with a known distinct 
media session, the problem of deciding which of them to render remains 
and has no obvious solution.

Possibly it only works well with a UA that has a sophisticated UI that 
can show you the multiple sessions and let you flip between them.

	Thanks,
	Paul

---

From: Gilad Shaham <[email-masked]>
Date: Mon, 8 Mar 2010 19:47:08 +0200

On Mon, Mar 8, 2010 at 7:20 PM, Paul Kyzivat <[email-masked]> wrote:

>>> I guess this would be something like the Reason header, or maybe it would
>>> really be the Reason header, though it would take some changes to allow it
>>> for that. Another possibility for this is Alert-Info.
>>>
>>

>> The only thing that's under the UAC's control is the offer, and AFAIK the
>> only thing the UAC can do to differentiate early media streams is somehow
>> assure that a different offer (with a different listening port) is used for
>> each offer. The UAC cannot do this if the offer is forked by a proxy.
>>
>>  ...
>>>
>>
>> And even worse: assuming that the UAC has the ability to play-out all the
>> potentially interesting media streams, there's no way for the UAC or the
>> user thereof to CANCEL any leg and thereby "stop" early media with today's
>> model. That's because one offer is used for all the early-media.
>>
>
> Several years ago Rohan proposed a model where the UAC did another O/A with
> each early dialog to move its media to a distinct port. That way it could
> then associate the signaling with a particular media stream. Seems
Perhaps a less cumbersome way to utilize the offer-answer is to send an
offer without actually allocating the port and only choose a port on each
dialog that indicates early media. this way the initiating UA has full
control and is not overwhelmed with several incoming streams. This of course
has a disadvantage if the call is answered very quickly (perhaps
automatically) which may require an additional UPDATE to hear something.

>> the media path (like say "Press 1 if you want to accept this call" and then
>> wait for a tone, or perhaps do speech-recognition), there's still no ability
>> for it to clean up the early media by signaling until the early media
>> becomes a regular media session.
>>
>> People claim to be worried about the media bandwidth impact of doing a 302
>> back to the UA and having it do the forking, but the simple fact is that at
>> least in this scenario the UA can control the result, whereas with proxy
>> parallel forking, the UA potentially gets hammered with multiple parallel
>> early media streams and has no way to do anything about it.
>>
>
> Yes. The cost and difficulty of the UAC handling the forking seems no worse
> that the extra O/As I mention above.
>
> media session, the problem of deciding which of them to render remains and
> has no obvious solution.
>
> Possibly it only works well with a UA that has a sophisticated UI that can
> show you the multiple sessions and let you flip between them.
>
> If we are relying on speech recognition or even tone detection, it sounds
very unlikely to become widely accepted. It's also very confusing for a
person to choose between those sessions and it doesn't make much sense for
the user to flip between them, unless the device could actually tell the
user there is something of great importance on that stream.

Once again, it means the other endpoints should indicate something about
their early media and as you said, PSTN is not covered by this option.
Still, maybe it's possible to leave PSTN as-is and concentrate on end-to-end
SIP.

Gilad

---

From: Dean Willis <[email-masked]>
Date: Mon, 8 Mar 2010 15:31:06 -0600

On Mar 8, 2010, at 11:20 AM, Paul Kyzivat wrote:

>
> I wasn't thinking of discriminating the early media streams, but  
> rather finding ways to eliminate them while retaining their intent.

That would be cool. Requires a business model change at PSTN gateways,  
which IMHO should go to 200 OK (and a fully-connected dialog) before/ 
while starting the IAM or equivalent on the PSTN side. But too many  
yerkaloids want to bill on 200OK.

But for non-gateway nodes, we could certainly do something along the  
lines of a 1xx header or specific cause-codes as different 1XX  
response types.

>
> Several years ago Rohan proposed a model where the UAC did another O/ 
> A with each early dialog to move its media to a distinct port. That  
> way it could then associate the signaling with a particular media  
> stream. Seems cumbersome, but maybe it will take something like that  
> to solve the problem.

Only works once the UAS sends back a 1xx of some sort. Some nodes just  
send media. For gateways, we therefore have to differentiate in the  
OFFER as seen by the UAS, which means sending a different offer to  
each UAS, which means NO  FORKING!

Or maybe we could do yet-another BCP on gateways to require early- 
dialog before media cut-through. This might be worth exploring. Of  
course, this requires updating all the gateways before it can be  
relied on, or at least probing for compliant gateways with a Require.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 8 Mar 2010 15:35:57 -0600

On Mar 8, 2010, at 11:47 AM, Gilad Shaham wrote:
>
> Perhaps a less cumbersome way to utilize the offer-answer is to send  
> an offer without actually allocating the port and only choose a port  
> on each dialog that indicates early media. this way the initiating  
> UA has full control and is not overwhelmed with several incoming  
> streams. This of course has a disadvantage if the call is answered  
> very quickly (perhaps automatically) which may require an additional  
> UPDATE to hear something.

So you're saying send an offerless INVITE and use early-dialogs to  
negotiate O/A with the UAS(gateway)  acting as the offering node? That  
might work.

> If we are relying on speech recognition or even tone detection, it  
> sounds very unlikely to become widely accepted. It's also very  
> confusing for a person to choose between those sessions and it  
> doesn't make much sense for the user to flip between them, unless  
> the device could actually tell the user there is something of great  
> importance on that stream.

I'm rather thinking more that a UA can engage in an "Are you there"  
challenge-response with the far end to see if there's something worth  
talking to.

Or the UA could record the media on each leg and play it back to the  
user later for diagnostic purposes.

> Once again, it means the other endpoints should indicate something  
> about their early media and as you said, PSTN is not covered by this  
> option. Still, maybe it's possible to leave PSTN as-is and  
> concentrate on end-to-end SIP.

Maybe. If gateways at least did "early session" with an answer in  
1xx,  along with some sort of SDP-to-RTP binding token (along the  
lines of the crypto one's we've discussed) we could make it work.

--
dean

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Mar 2010 07:36:13 +0100

Hi,

Would it be possible to use the 3xx mechanism in order to solve the forking related problems with SUB/NOT (as described in 3265bis)?

The forking proxy would return a 3xx response to the SUBSCRIBE request, and the UAC can then send individual SUBSCRIBE requests to each UAS?

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Mar 2010 00:13:57 -0700

The only real way you could deploy this would be with a 'proxy-require' 
option tag that would have associated semantics that forbid proxies from 
forking. I don't think that's very tractable at this point.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Mar 2010 08:28:56 +0100

Hi,

I don't think we can "forbid" the proxy from forking, and if it does we have to live with the consequences.

The proposal for OPTIONS 3xx (and, I guess it would be the same for INVITE 3xx?) is to use the Request-Disposition to header to indicate a wish to redirect. But, then if of course depends on whether support for R-D is implemented in proxies or not. If not implemented things will work as today - with all the consequences.

Note, however, that I am not suggesting to replace 3265bis with SUB 3xx - I was only asking whether it could be used to solve the problems described.

Regards,

Christer 

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: 23. maaliskuuta 2010 9:14
To: Christer Holmberg
Cc: SIPCORE
Subject: Re: [sipcore] SUBSCRIBE 3xx - can it solve issues raised in 3265bis? [was INVITE 3xx and early media]

The only real way you could deploy this would be with a 'proxy-require' 
option tag that would have associated semantics that forbid proxies from forking. I don't think that's very tractable at this point.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Mar 2010 10:47:09 -0400

Yes, of course its possible to use R-D to request redirect, as long as 
you are satisfied with the possibility that it won't be honored.

	Thanks,
	Paul

---

From: "WORLEY, DALE R (DALE)" <[email-masked]>
Date: Tue, 23 Mar 2010 14:01:20 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christer Holmberg [[email-masked]]

A UA can send SUBSCRIBE with "Request-Disposition: no-recurse", but there's no guarantee that every proxy on the way will obey it.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Mar 2010 00:05:39 +0100

Hi,
 
>>>>>be generated and something must happen to it. The only question is which of the bad 
>>>>>solutions you prefer.
>>>>>
>>>>>code, another playing an out-of- service tone, and a third sending 
>>>>>no media which will eventually pick up with a real person. What would you *like* for the 
>>>>>caller to hear?
>>>>For this reasons you have B2BUAs, application servers, gating nodes 
>>>>etc, that at least TRY to deal with the problem, to ensure that whatever the user 
>>>>eventually hears, at least the quality will be good.
>>Leaving PSTN interworking aside, most early media (at least the one of real importance) will 
>>be generated by application servers/B2BUAs in the network, and they will normally be able to 
>>control the media pretty well. A SIP UA might generate something, but unless it's a Henry 
>>Sinnreich device (where all the services are implemented in the end device :) I don't think 
>>UAs will normally send service related announcement etc.
>
>I gather you are arguing that there just aren't many calls with early media. But "leaving 
>PSTN interworking aside" isn't really fair, since there is so much of that.

I agree. My intention was only to say that the only "endpoints" that are likely to send early media in most cases are PSTN networks.

>For instance there could be a lot of the google service that simply forks calls to multiple 
>PSTN lines. And don't most pstn calls have in-band ringback? That would get multiple early 
>media, though if its just ringback it doesn't matter if you play it or not. But if one of 
>those becomes defective and starts playing out of service messages then it does matter which 
>one you play.

Yes.

>>Of course, if you have application servers sending media both in the originating and 
>>terminating network, there need to be some policy procedures on which media has higher 
>>priority etc.
>
>Policy doesn't help a lot. It content, not policy, that determines which is important to 
>hear.

Sure, but there can be policy that says "My early media is more important that anything else".

Having said that, having information abouot the content would probably be very useful. However, I don't think it would help in the PSTN interworking case, becase the MGC most likely does not know what early media (in-band ringing or service anouncement) comes from the PSTN network.

>Perhaps the best we can do is discourage the use of early media for anything important.

I guess it depends on what you mean by "important", but there are a number of services that rely on early media.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Mar 2010 19:11:15 -0400

My conclusion is that none of the suggestions being thrown around 
fundamentally improve the handling of early media in any way. Its just a 
mess, and there is no feasible solution.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Mar 2010 00:16:21 +0100

Hi,

Maybe RFC 4574 could be used.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 8. maaliskuuta 2010 16:38
To: Gilad Shaham
Cc: Christer Holmberg; 'SIPCORE'
Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?]

Gilad Shaham wrote:
> interest, perhaps it's possible to add a header/parameter conveying 
> the nature of the media stream (ringback, service message, voice, 
> etc.). This is similar to the content-disposition handling parameter, 
> but more informative than "optional" and "required". This way, a B2BUA 
> would be able to choose the stream to forward and even without a 
> B2BUA, an endpoint receiving several streams would know which stream to play back to the user.

I guess this would be something like the Reason header, or maybe it would really be the Reason header, though it would take some changes to allow it for that. Another possibility for this is Alert-Info.

The response code, possibly augmented with the Reason header, would work for things like out of service that are going to cause the call to fail. 
However the callee has to have confidence that the caller will be properly informed of the case.

The Alert-Info containing a URN can potentially work for common things that aren't going to cause the call to fail. But that isn't sufficient if there is variable information to convey to the caller, unless it is done with with a URI that can be dereferenced and rendered. The latter would be an alternative if we could convince UAs to render such things. 
My impression is that there is reluctance to do so, though it really isn't much different from rendering an early media string.

But none of this will help with many pstn interop cases where the reason isn't known except through the content of the media.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Mar 2010 00:28:59 +0100

Hi, 

>That would be cool. Requires a business model change at PSTN gateways, which IMHO should go 
>to 200 OK (and a fully-connected dialog) before/ while starting the IAM or equivalent on the 
>PSTN side. But too many yerkaloids want to bill on 200OK.

It is not only about business models.

Using 200 OK would ensure that all but one dialog is terminated, but there can still be multiple sources of early media.

>But for non-gateway nodes, we could certainly do something along the lines of a 1xx header or 
>specific cause-codes as different 1XX response types.
>
>
>Only works once the UAS sends back a 1xx of some sort. Some nodes just send media. For 
>gateways, we therefore have to differentiate in the OFFER as seen by the UAS, which means 
>sending a different offer to each UAS, which means NO  FORKING!

I think that UASs should send back a 1xx of some sort.

>Or maybe we could do yet-another BCP on gateways to require early- dialog before media cut-
>through. This might be worth exploring. Of course, this requires updating all the gateways 
>before it can be relied on, or at least probing for compliant gateways with a Require.

Or, we may want to only SDP only to establish a control channel for some other media negotiation protocol, used between the UAC and each UAS ;)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Mar 2010 00:34:19 +0100

Hi,

Since there is no protocol mechanism to handle this, I guess policy (whatever it is based upon) is the only option. It may work well or bad, but if it's the only option...

Regards,

Christer 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 24. maaliskuuta 2010 1:11
To: Christer Holmberg
Cc: 'Dean Willis'; SIPCORE
Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?]

My conclusion is that none of the suggestions being thrown around fundamentally improve the handling of early media in any way. Its just a mess, and there is no feasible solution.

	Thanks,
	Paul

Christer Holmberg wrote:
> Hi,
>  
>>>>>> If you want parallel forking, even if done by the UAC, there is 
>>>>>> no good solution to this problem. The parallel early media is 
>>>>>> going to be generated and something must happen to it. The only 
>>>>>> question is which of the bad solutions you prefer.
>>>>>>
>>>>>> For instance, you may have one stream asking you to enter an 
>>>>>> access code, another playing an out-of- service tone, and a third 
>>>>>> sending no media which will eventually pick up with a real 
>>>>>> person. What would you *like* for the caller to hear?
>>>>> For this reasons you have B2BUAs, application servers, gating 
>>>>> nodes etc, that at least TRY to deal with the problem, to ensure 
>>>>> that whatever the user eventually hears, at least the quality will be good.
>>>> out-of-service tone, and so hang up even though the call was 
>>>> ringing elsewhere, but without any ringback.
>>>>
>>> As I've said before, I don't think there is a very big risk that the 
>>> "wrong" early media would be presented to you.
>>>
>>>
>>> Leaving PSTN interworking aside, most early media (at least the one 
>>> of real importance) will be generated by application servers/B2BUAs 
>>> in the network, and they will normally be able to control the media 
>>> pretty well. A SIP UA might generate something, but unless it's a 
>>> Henry Sinnreich device (where all the services are implemented in the end device :) I don't think UAs will normally send service related announcement etc.
>> media. But "leaving PSTN interworking aside" isn't really fair, since there is so much of that.
> 
>> For instance there could be a lot of the google service that simply 
>> forks calls to multiple PSTN lines. And don't most pstn calls have 
>> in-band ringback? That would get multiple early media, though if its 
>> just ringback it doesn't matter if you play it or not. But if one of 
>> those becomes defective and starts playing out of service messages then it does matter which one you play.
> 
> Yes.
> 
>>> Of course, if you have application servers sending media both in the 
>>> originating and terminating network, there need to be some policy 
>>> procedures on which media has higher priority etc.
>> Policy doesn't help a lot. It content, not policy, that determines 
>> which is important to hear.
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Mar 2010 21:06:19 -0500

> mess, and there is no feasible solution.

Arguably, not forking in a proxy helps. It least lets you know how to
kill an early media stream that is being spewed back at you.

Offerless INVITEs help more, since the media can't come back to you
until the O/A has completed.

What if we split the O/A stage into three phases:

1) pre-offer: Alice INVITES Bob, includes a description of media she can
send and receive but not an IP address or port number

2) offer: Bob sends Alice a description of the media he expects to send
and to receive, along with the IP addresses and port numbers he is going
to use.

3) answer: Alice sends Bob the IP addresses and port number to whichs he
should direct media and from which Alice will be sending media.

Note that this eliminates early media. Bob can't send Alice any media
until he receives the answer.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Mar 2010 21:11:30 -0500

Christer Holmberg wrote:

>> That would be cool. Requires a business model change at PSTN
>> gateways, which IMHO should go to 200 OK (and a fully-connected
>> dialog) before/ while starting the IAM or equivalent on the PSTN
>> side. But too many yerkaloids want to bill on 200OK.
> 
> Using 200 OK would ensure that all but one dialog is terminated, but
> there can still be multiple sources of early media.
> 

No, I'm suggesting that all of the forks respond with a 200 OK and move
to a connected state, not just the first fork to respond. It's not a
race, and there is NO early media -- just media being sent before the
PSTN side of the gateway moves to a fully-connected state. Sorting out
multiple media streams is a separate problem, but there are ways to
automate many cases in a B2BUA or really smart UA.

But this breaks the business model, which assumes that everything
everywhere is fully-connected and in a "billing starts" state when the
first 200OK flies.

--
dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Mar 2010 23:55:56 -0400

> kill an early media stream that is being spewed back at you.

Well, that depends.

Its really only parallel forking thats a problem, so we can probably 
ignore serial forking.

For parallel forking, moving it from the proxy to the UAC doesn't really 
solve the problem - you can still end up with multiple media streams and 
no clue what to do with them.

You can say "don't do that", but there are desirable features that 
depend on it - namely "simultaneous ring". Potentially that can be 
replaced with presence-sensitive ringing to choose the *right* on to 
ring first, but that requires data that often isn't available.

> until the O/A has completed.

That is just sticking your head in the sand. The media is still being 
generated, even if you don't know about it.

It does have the advantage that you can associate the media stream to 
the signaling source, but it still doesn't tell you which stream is 
interesting to listen to.

ISTM that if you want "simultaneous ring", and the things ringing are 
often PSTN devices, there is still no solution. Perhaps there is some 
possibility of automated media analysis - the pstn GW figuring out that 
the media being received is something uninteresting - just conventional 
ringback - and suppressing it. But thats a lot of trouble and is likely 
to have a high error rate.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Mar 2010 17:51:44 +0100

Hi,

>PSTN side of the gateway moves to a fully-connected state.
>
>Sorting out multiple media streams is a separate problem, but there are ways to

But, what problem would that solve? 

The only difference is in what state you are (established-dialog instead of early-dialog), but you still have the same problem as duing the early dialog phase: you might receive early media from multiple locations. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Mar 2010 18:08:28 +0100

Hi,

>>Offerless INVITEs help more, since the media can't come back to you until the O/A has completed.
>
>That is just sticking your head in the sand. The media is still being generated, even if you don't know about it.
>

Exactly. And, in my opinion THAT is the big problem.

Being able to associate a media stream with dialog is of course very useful, and there are ways to do that (including the one presented by Dean), but it doesn't solve the problem with multiple early media.

>to have a high error rate.

Correct. And, as long as the protocol allows forking, I think it is not possible to define a protocol mechanism how to solve the problem.

We can define information elements which contain information about the early media (eventhough it most likely won't work in the PSTN case), but at the end of the day you will need policy rules in order to decide what media is forwarded or played to the calling user. 

Regards,

Christer

---

From: Gilad Shaham <[email-masked]>
Date: Wed, 24 Mar 2010 19:48:19 +0200

Even if you would define policy, that doesn't mean it doesn't make sense to
provide information on the nature of the media from non-PSTN sources. So you
could say (in policy), for example, that PSTN is more important than just a
ringback tone, but not more important than an IVR.

My main question is whether we actually see in practice these scenarios to
warrant a header/parameter/attribute that indicates the nature of the early
media. In any case, I personally don't believe a B2BUA or phone would ever
be smart enough to know which stream to pass through. Even the smart ones
usually allow the first stream and block the rest. The reason is simple - if
it were easy to do that, solving the PSTN question would also be easy.

On Wed, Mar 24, 2010 at 7:08 PM, Christer Holmberg <
[email-masked]> wrote:

> Being able to associate a media stream with dialog is of course very
> useful, and there are ways to do that (including the one presented by Dean),
> but it doesn't solve the problem with multiple early media.
>
> Correct. And, as long as the protocol allows forking, I think it is not
> possible to define a protocol mechanism how to solve the problem.
>
> We can define information elements which contain information about the
> early media (eventhough it most likely won't work in the PSTN case), but at
> the end of the day you will need policy rules in order to decide what media
> is forwarded or played to the calling user.
>
> Regards,
>
> Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Mar 2010 19:01:47 +0100

Hi,

>Even if you would define policy, that doesn't mean it doesn't make sense to provide information on the nature of the media from
>non-PSTN sources.

I agree. I think it would be very useful, and you would be able to define better and more reliable policies.

>So you could say (in policy), for example, that PSTN is more important than just a ringback tone, but not more important than an
>IVR.

Yes.

>My main question is whether we actually see in practice these scenarios to warrant a header/parameter/attribute that indicates the
>nature of the early media. In any case, I personally don't believe a B2BUA or phone would ever be smart enough to know which
>stream to pass through. Even the smart ones usually allow the first stream and block the rest. The reason is simple - if it were easy
>to do that, solving the PSTN question would also be easy.

I haven't seen any headers/parameters, but at least in 3GPP there is currently an ongoing discussion on whether some header/parameter would be needed for some specific services using early media.

Regards,

Christer

On Wed, Mar 24, 2010 at 7:08 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Brett Tate <[email-masked]>
Date: Wed, 24 Mar 2010 12:01:49 -0700

If rfc3959 was actually supported, doesn't it solve many of the forking related early media issues?  And the use of 199 addresses the ambiguity of knowing if an early dialog/session actually still exists.

What still needs to be addressed for early media to work when forking is involved?

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Dean Willis [[email-masked]]
Sent: Tuesday, March 23, 2010 10:06 PM
To: Paul Kyzivat
Cc: SIPCORE
Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?]

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Mar 2010 23:11:07 +0100

Hi,

>If rfc3959 was actually supported, doesn't it solve many of the forking related early media issues?

3959 allows you to provide an early-media specific SDP (there are other ways of doing that also).

The early-session SDP also works as an indicator that there will be early media in the first place, but there are other ways of doing that also (e.g. using the P-Early-Media header).

But, the problem is still there: there might be multiple early media streams.

>And the use of 199 addresses the ambiguity of knowing if an early dialog/session actually still exists.

True. It helps to indicate on which dialogs there will NOT be any additional early media.

But, it also doesn't solve the issue of having multiple active early media streams.

>What still needs to be addressed for early media to work when forking is involved?

I think the main problem is having multiple early media streams. How do you decide which to play or forward to the calling user?

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Thu, 25 Mar 2010 09:53:39 -0700

> I think the main problem is having multiple early media streams. How do you decide 
> which to play or forward to the calling user?

RFC 3959 basically allows the caller or caller's device to decide.  It can play, ignore, reject, or conference the early media and then switch to the answered media when appropriate.

Concerning "forward to the calling user", they all can be forwarded unless there is a middle box attempting to control things with or without input from calling party.  Without input from the calling party, I agree that it can potentially lead to non desirable experience for the user.

If the user's device and outbound middle boxes are not able to handle the simultaneous media for RFC 3959, I assume something could be defined (if caller prefs is not adequate) to allow calling party and/or middle boxes to force/request sequential forking.  However similar to solely relying upon 3xx's and attempting targets sequentially, this can lead to long call-setup times before finally reaching voice mail or a party likely to answer.  In comparison to a 3xx solution, the sequential solution at least still allows the calling party to maintain a little more control over the order/timing related to trying the various targets.

---

From: Gilad Shaham <[email-masked]>
Date: Thu, 25 Mar 2010 19:30:35 +0200

In my experience, many implementations may actually do wrong things when
faced with multipart containing several SDPs. They should not, but in
practice this happens. Even if we do choose this over any other mechanism
proposed (such as 3xx), I would recommend we do not rely on RFC 3959 to
indicate the nature of the media.

On Thu, Mar 25, 2010 at 6:53 PM, Brett Tate <[email-masked]> wrote:

> RFC 3959 basically allows the caller or caller's device to decide.  It can
> play, ignore, reject, or conference the early media and then switch to the
> answered media when appropriate.
>
> Concerning "forward to the calling user", they all can be forwarded unless
> there is a middle box attempting to control things with or without input
> from calling party.  Without input from the calling party, I agree that it
> can potentially lead to non desirable experience for the user.
>
> If the user's device and outbound middle boxes are not able to handle the
> simultaneous media for RFC 3959, I assume something could be defined (if
> caller prefs is not adequate) to allow calling party and/or middle boxes to
> force/request sequential forking.  However similar to solely relying upon
> 3xx's and attempting targets sequentially, this can lead to long call-setup
> times before finally reaching voice mail or a party likely to answer.  In
> comparison to a 3xx solution, the sequential solution at least still allows
> the calling party to maintain a little more control over the order/timing
> related to trying the various targets.

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Mar 2010 13:12:11 -0500

Christer Holmberg wrote:
>> No, I'm suggesting that all of the forks respond with a 200 OK and
>> move to a connected state, not just the first fork to respond. It's
>> not a race, and there is NO early media -- just media being sent
>> before the PSTN side of the gateway moves to a fully-connected
>> state.
>> 
>> Sorting out multiple media streams is a separate problem, but there
>> are ways to automate many cases in a B2BUA or really smart UA.
>> 
>> everywhere is fully-connected and in a "billing starts" state when
>> the first 200OK flies.
> 
> The only difference is in what state you are (established-dialog
> instead of early-dialog), but you still have the same problem as
> duing the early dialog phase: you might receive early media from
> multiple locations.
> 

It's not "early media" if it is in an established dialog. Once you have
a full dialog, you can do  things like send a "BYE", have a bot do a
verbal challenge-response on the media path, play one channel to the
left ear and one to the right, play all of the media flows
simultaneously with variable volume weighting using a hover-touch over a
per-session icon (click to pick "this call" and drop the other ones),
etc. But "early media" messes everything up.

--
dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Mar 2010 13:19:40 -0500

> Its really only parallel forking thats a problem, so we can probably

Not really. Early media is always a problem. How do you tell it to stop
without whacking all your forks?

> no clue what to do with them.

Knowing which stream is which lets you do MORE things than you can with
just a bunch of garbled media coming in.

> ring first, but that requires data that often isn't available.

Google Voice does simultaneous ring quite nicely. If you call my GV
number, it will ring all my phones. If somebody answers a phone, GV will
say "Press 1 to accept a call from Paul Kyzivat", and if I press 1, GV
will terminate the other forks.

Webster did this years ago using the dynamicsoft stuff as a call controller.

But to do this kind of work, the call controller needs signaling control
on each fork, which you don't get with early media.

> generated, even if you don't know about it.

No, really. They CANNOT send you media until you've sent your SDP.  If
you don't send your SDP (in the ACK) until they have sent theirs (in the
200OK), then there is NO EARLY MEDIA.

Yes, this means that PSTN gateways would have to complete ACK before
doing IAM on the PSTN side. I'm OK with that.

> interesting to listen to.

But having associated signaling lets you do things to decide which one
is interesting.

> to have a high error rate.

Go play with Google Voice or something like it for awhile and then get
back to us.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Mar 2010 15:08:03 -0400

[speaking as an individual]

Brett,

Its true that the caller MAY choose to render whatever it wants from the 
multiple media streams coming back. And thats fine if none of them 
contain anything of consequence.

But it doesn't alter reality. One, or more, of those early media streams 
may contain information that the caller needs to hear. When the caller's 
UA chooses, it may pick one that is unimportant over one that is 
important. And even picking one that is important isn't good enough if 
another was also important.

If the streams were identifiable (by automata) as to content, then at 
least an important one might be chosen over an unimportant one. I can 
only see two answers for the case where more than one has important content:

- indicate to the caller that there are multiple, and permit the
   caller to toggle between them

- indicate to the callee that its early media will not be rendered.
   Force it to wait to send until such time as it can be rendered.

Those two are actually complementary.

Unfortunately, the pstn media is probably by far the most common case. 
And with it:
- we have no indicatino of what the content is (do we?)
- indicating refusal to accept the media will not delay it,
   only cause it to be dropped.

	Thanks,
	Paul

---

From: [email-masked]
Date: Fri, 26 Mar 2010 04:50:16 +0800

IMO, if the caller's UE is as strong as Google Voice and it's software, 
the network can just render all the early media to it.
So, the key problem is about UE with less capability.

I still think it is BCP thing. I once said how my equipment handle this in 
the 
mail(http://www.ietf.org/mail-archive/web/sipcore/current/msg02114.html).

BTW, doing this can make PSTN user having the same experience as GV:
PSTN gateway(such as MGCF in IMS) terminate the multiple forked early 
media and just send only one to the PSTN user. And using DTMF, the user 
can switch from one voice to another by press the number key. 

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Dean Willis <[email-masked]> 
发件人:  [email-masked]
2010-03-26 02:19

收件人
Paul Kyzivat <[email-masked]>
抄送
SIPCORE <[email-masked]>
主题
Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not 
to fork?]

Webster did this years ago using the dynamicsoft stuff as a call 
controller.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: [email-masked]
Date: Fri, 26 Mar 2010 05:14:48 +0800

Hi Paul,

I agree most of your points. And aout PSTN case, there's one tiny 
discussion, please see inlines.

Thanks,

Gao

> to have a high error rate.

[Gao] I once had the same viewpoint. But now I guess the gateway can let 
the caller choose from the multiple early media with out media analysis. 
Such as "Press 2 to choose the second early media".
If the gateway support VoiceXML or some other IVR mechanism, it can format 
the voice by the callee's URI, such as "Press 2 to listen to Alice".

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Mar 2010 04:51:08 +0100

Hi,

>> multiple locnennations.
>It's not "early media" if it is in an established dialog.

True. But I don't understand why that is relevant in this context. The problem is that you are receiving media from multiple locations, so I don't see how it matters whether you are in the early dialog phase or not.

>Once you have a full dialog, you can do  things like send a "BYE"

I don't remember if you're allowed to send BYE in the forward direction on an early dialog (you cannot send it in the backward direction, which is one reason we have this wonderful thing called 199 :), but if you can't you can always send a new offer with "inactive" (eventhough the early dialog itself will not be terminated).

However, I am not sure you always want to terminate dialogs. Just because you don't "like" the before-the-remote-user-has-picked-up-the-hook media it doesn't mean you necessarily want to terminate the whole dialog.

>have a bot do a verbal challenge-response on the media path,

Why can't you do that with early media? 

> play one channel to the left ear and one to the right,

You can do that with early dialogs also.

And, if the user have to listen at both channels at the same time, it is still going to be messy even you use "stereo".

>play all of the media flows simultaneously with variable volume weighting using a hover-touch over a

Sure, it may work with geeky users using fancy equipment.

It doesn't work for PSTN (DTMF is the best you can get there), and I don't think it would work with the average user who just wants to make a call.

And, again, you may not even have enough bandwidth to forward media to the calling user in the first place. I don't think networks are designed that way.

>etc. But "early media" messes everything up.

Simultanous media from multiple remote locations messes things up.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Mar 2010 05:06:24 +0100

Hi,

>>Its really only parallel forking thats a problem, so we can probably ignore serial forking.
>
>Not really. Early media is always a problem. How do you tell it to stop without whacking all your forks?

"inactive".

Some anouncement based services also use DTMF control to control the media.

>>For parallel forking, moving it from the proxy to the UAC doesn't really solve the problem - you can still end up with 
>>multiple media streams and no clue what to do with them.
>

Knowing which stream is which - AND knowing something about the content of the media.

>will terminate the other forks.

But, at that poing the call has been answered by Paul. It is whatever happens before that (no matter whether the call, from a SIP perspective, is in the early dialog phase or not) that is the problem.

>on each fork, which you don't get with early media.

It does if you create a dialog, using 18x (or, as you suggest, 200) before playing the media.

(The fact that SIP allows media to be sent before any response has been sent is a bug, in my opinion.)

>doing IAM on the PSTN side. I'm OK with that.

But, if the ACK is sent to multiple remote destinations at the same time you are still going to end up with the same media-from-multiple-locations problem - it will just occur a little later.

If you do NOT want to send ACK to multiple remote destinations at the same time, you can as well to serial forking to start with.

>But having associated signaling lets you do things to decide which one

Having signalling which gives information about the content of the media, yes. I agree that would be useful.

But, using your offerless-INVITE-mechanish is not going to give you any more information about the content of the media. It only allows you to not receive media until you've sent the ACK.

>Go play with Google Voice or something like it for awhile and then get

Does GV have the possibility to receive media (other than "meaningless" ringtones) from multiple locations?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Mar 2010 05:10:20 +0100

Hi,

>IMO, if the caller's UE is as strong as Google Voice and it's software, the network can just render all the early media to it.
>I still think it is BCP thing. I once said how my equipment handle this in the mail(http://www.ietf.org/mail->archive/web/sipcore/current/msg02114.html).
>
>PSTN gateway(such as MGCF in IMS) terminate the multiple forked early media and just send only one to the PSTN user. And
>using DTMF, the user can switch from one voice to another by press the number key.

That could work if the media isn't actually played until it is "chosen" (using DTMF). If the early media A and B is played at the same time, the user will miss B while listening to A, and when the user switches to B the message may already be over...

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Mar 2010 18:53:43 -0500

On Sat, 2010-03-27 at 04:51 +0100, Christer Holmberg wrote:

> 
> True. But I don't understand why that is relevant in this context. The
>  problem is that you are receiving media from multiple locations, so I
>  don't see how it matters whether you are in the early dialog phase or
>  not.
> 

The problem is not just that you are receiving media from multiple
locations. It's that you're receiving data from multiple locations, you
don't know who those locations are or anything else about them, and you
have no way to stop the media nor manipulate it in any useful way
besides just discarding it.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Mar 2010 19:00:03 -0500

> >Not really. Early media is always a problem. How do you tell it to stop without whacking all your forks?

You can't send it an inactive because it hasn't sent you an answer yet,
so you can't target that fork with an inactive.

> But, if the ACK is sent to multiple remote destinations at the same
>  time you are still going to end up with the same
>  media-from-multiple-locations problem - it will just occur a little
>  later.

There's a difference between having multiple active dialogs, each with
related media, and having a bunch of early-media streams just coming at
you outside of a dialog context.

In this case, it's a different set of ACKs -- the caller could, for
example, serialize the acks and resort the order based on
application-determined probability of an interesting result. Or pick one
to play to the user and three more to hand to a challenge-response bot
just in case a human answers.

> But, using your offerless-INVITE-mechanish is not going to give you any
>  more information about the content of the media. It only allows you to
>  not receive media until you've sent the ACK.

Which gives you the "identity" aof the fork-terminator and any further
related information that might be available before sending the ACK.

>  Does GV have the possibility to receive media (other than
>  "meaningless" ringtones) from multiple locations?
> 

Yes. It uses an IVR to challenge the recipient and decide which fork to
"complete".

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Mar 2010 04:53:58 +0200

Hi, 

>The problem is not just that you are receiving media from multiple locations. It's that you're receiving data from multiple locations, you don't know who those locations are or anything else about them, 
>and you have no way to stop the media nor manipulate it in any useful way besides just discarding it.

That is the case if you receive media before you have received ANY response (18x or 200), yes, and personally I think it should not be allowed to send media in that way. "Fortunately", in many environments, such early media will never reach the UAC (due to gating procedures etc), so hopefully it will encourage people not to send early media that way :)

But, IF the UAS sends a 18x, and establishes an early dialog, I don't see the difference.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Mar 2010 05:04:37 +0200

Hi,

>You can't send it an inactive because it hasn't sent you an answer yet, so you can't target that fork with an inactive.

I think we talk about different "early media" scenarios.

You talk about the case when there is NO answer coming from the UAS before the early media, while I talk about the case when there IS an answer (received in a 18x) before the early media.

I AGREE with the issues related to your case, and I have not been arguing against those :) 

As I've said earlier, sending early media before an answer is not good, in my opinion.

I think the issue is that you and I have different solutions to that problem: you think that a 200 OK should be sent before any media is sent, while I think it is enough to send a 18x.

>There's a difference between having multiple active dialogs, each with related media, and having a bunch of early-media streams just coming at you outside of a dialog context.

I totally agree. Each media stream should have an associated dialog. But, that dialog could be an early dialog.

>Yes. It uses an IVR to challenge the recipient and decide which fork to "complete".

But, does it play the IVR message at the same time as the "ringtones" (which could also be anouncements), or does it not even contact the remote terminals before the work to complete has been chosen?

Regards,

Christer

---

From: [email-masked]
Date: Wed, 31 Mar 2010 11:33:02 +0800

IMO, as the PSTN's terminal has no ability to handle more than one channel 
of media, I think it is hardly to handle it better.
If you have one better solution/suggestion, please share it to us.

Then, about the normative/BCP, I prefer it to be BCP, as how to handle it 
should be open ways.

Thanks,

Gao

Christer Holmberg <[email-masked]> 
发件人:  [email-masked]
2010-03-27 12:10

收件人
"[email-masked]" <[email-masked]>, Dean Willis 
<[email-masked]>
抄送
SIPCORE <[email-masked]>
主题
Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not 
to fork?]

Hi,

>I still think it is BCP thing. I once said how my equipment handle this 
in the mail(http://www.ietf.org/mail-
>archive/web/sipcore/current/msg02114.html).
>
media and just send only one to the PSTN user. And
>using DTMF, the user can switch from one voice to another by press the 
number key.

That could work if the media isn't actually played until it is "chosen" 
(using DTMF). If the early media A and B is played at the same time, the 
user will miss B while listening to A, and when the user switches to B the 
message may already be over...

Regards,

Christer

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Mar 2010 07:45:48 +0200

Hi, 

>IMO, as the PSTN's terminal has no ability to handle more than one channel of media, I think it is hardly to handle it better. 

Trust me, I wish I had a solution.

Regards,

Christer

	2010-03-27 12:10 

		收件人
		"[email-masked]" <[email-masked]>, Dean Willis <[email-masked]> 
		抄送
		SIPCORE <[email-masked]> 
		主题
		Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?]

	Hi,

	

	Regards,

	Christer