Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] //copy from the sipcore Discussion Archive

From: [email-masked]
Date: Mon, 8 Mar 2010 09:20:50 +0800

Hi,

Sorry for copy the mail from archive(I can not recv sipcore mails these 
days).

inlines.

Thanks,

Gao

From: Paul Kyzivat <pkyzivat at cisco.com> 
To: Christer Holmberg <christer.holmberg at ericsson.com> 
Cc: SIPCORE <sipcore at ietf.org> 
Date: Sun, 07 Mar 2010 11:47:34 -0500 
In-reply-to: <FF84A09F50A6DC48ACB6714F4666CC745C10EE4166 at 
ESESSCMS0354.eemea.ericsson.se> 
References: <FF84A09F50A6DC48ACB6714F4666CC745C10EE415F at 
ESESSCMS0354.eemea.ericsson.se> <AEA0E9BF-8B6A-4AAA-81B6-A7C68F6B7309 at 
softarmor.com> <FF84A09F50A6DC48ACB6714F4666CC745C1102CCCD at 
ESESSCMS0354.eemea.ericsson.se> <4B918DED.6090108 at cisco.com> 
<FF84A09F50A6DC48ACB6714F4666CC745C1102CCD1 at 
ESESSCMS0354.eemea.ericsson.se>, <4B919413.60506 at cisco.com> 
<FF84A09F50A6DC48ACB6714F4666CC745C10EE4166 at 
ESESSCMS0354.eemea.ericsson.se> 

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

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.

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. 

[Gao] I agree. The forking proxy/AS have no way to know the contents of 
early media currently. So, it is not proper to judge which one is more 
important and do filter things. 

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. 

[Gao] Yes.

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

[Gao] As many operating equipment/network has used early media for 
someting important as DTMF number collecting or code collecting, 
discourage the usage may cause interworking and compatible problem.

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

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