[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Early media as an endpoint application
Hi,
>>How would the proposed "Media Before Answer" endpoint/gateway
>>application affect the billing in your opinion? Would it change
>>nything with the issues here below?
>
>If you wanted to bill on signaling, the billing nodes would need to be
able to differentiate between the "early" session >and the "real"
session. They might could do this by noting the initiator of the session
if a "repalces" model or
>"reinvite" model is used, or by adding a header field.
The differentiation is based on what comes before 200 OK, and what comes
after.
I am not sure how separate/replaced dialogs etc would help.
I don't think early media as such is the problem, but (as others have
also said) forking. And, to be precise: parallel forking.
Two potential solutions:
1. Forbid parallel forking.
- That is probably no problem whFrom sip-bounces at ietf.org Fri Aug 22 14:44:45 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-web-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4A0193A6942;
Fri, 22 Aug 2008 14:44:45 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A6FF73A6942
for <sip at core3.amsl.com>; Fri, 22 Aug 2008 14:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.077
X-Spam-Level:
X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.172,
BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id AwJsOLF8tDAn for <sip at core3.amsl.com>;
Fri, 22 Aug 2008 14:44:41 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60])
by core3.amsl.com (Postfix) with ESMTP id 859963A68AA
for <sip at ietf.org>; Fri, 22 Aug 2008 14:44:40 -0700 (PDT)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
D0FCD205AB; Fri, 22 Aug 2008 23:44:38 +0200 (CEST)
X-AuditID: c1b4fb3c-ac8cbbb0000015b5-24-48af3346f205
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
AE9902058B; Fri, 22 Aug 2008 23:44:38 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 22 Aug 2008 23:44:35 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 22 Aug 2008 23:44:31 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0791B680 at esealmw113.eemea.ericsson.se>
In-Reply-To: <E716F8E2-A025-4F66-B406-4941891FD94C at softarmor.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Early media as an endpoint application
thread-index: AckEfXiqFXjhtBLGQHiRIsm0hysP5AAIQWwg
References: <C4D3467D.7CF3%hsinnrei at adobe.com>
<E716F8E2-A025-4F66-B406-4941891FD94C at softarmor.com>
From: "Christer Holmberg" <christer.holmberg at ericsson.com>
To: "Dean Willis" <dean.willis at softarmor.com>,
"Henry Sinnreich" <hsinnrei at adobe.com>
X-OriginalArrivalTime: 22 Aug 2008 21:44:35.0554 (UTC)
FILETIME=[44FDEC20:01C904A0]
X-Brightmail-Tracker: AAAAAA==
Cc: sip at ietf.org, ekr at rtfm.com, Dan Wing <dwing at Cisco.COM>
Subject: Re: [Sip] Early media as an endpoint application
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Hi,
>>How would the proposed "Media Before Answer" endpoint/gateway
>>application affect the billing in your opinion? Would it change
>>nything with the issues here below?
>
>If you wanted to bill on signaling, the billing nodes would need to be
able to differentiate between the "early" session >and the "real"
session. They might could do this by noting the initiator of the session
if a "repalces" model or
>"reinvite" model is used, or by adding a header field.
The differentiation is based on what comes before 200 OK, and what comes
after.
I am not sure how separate/replaced dialogs etc would help.
I don't think early media as such is the problem, but (as others have
also said) forking. And, to be precise: parallel forking.
Two potential solutions:
1. Forbid parallel forking.
- That is probably no pren forking occurs "in the network", for
example when a request is first forked to an anouncement server, and
after that towards the called user. I believe serial forking is mostly
used in such scenarios - and 199 helps to indicate when one forked leg
is "finished" :)
- That is probably a problem when a registrar forks, because it would
take a long time before all of the called user's terminals would be
given a chance to "ring". Once the registrar has tried all terminals the
calling user has probably hang up...
2. Terminate forking already on 18x
- When a forking proxy receives a 18x (with SDP) on one leg, it would
terminate all other legs. That is very similar to Dean's proposal on
sending 200 OK already for early media (but it would not affect charging
models etc which are based on the assumption that 200 OK means that the
user has answered).
- The problem, as Dean said earlier, is of course that the one that the
entity that first starts to send early media (and 18x) may not be the
entity that would accept the call. But, since all other legs would be
terminated, the only entity which can accept the call is the one who
send 18x first.
Regards,
Christer
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
oblem when forking occurs "in the network", for
example when a request is first forked to an anouncement server, and
after that towards the called user. I believe serial forking is mostly
used in such scenarios - and 199 helps to indicate when one forked leg
is "finished" :)
- That is probably a problem when a registrar forks, because it would
take a long time before all of the called user's terminals would be
given a chance to "ring". Once the registrar has tried all terminals the
calling user has probably hang up...
2. Terminate forking already on 18x
- When a forking proxy receives a 18x (with SDP) on one leg, it would
terminate all other legs. That is very similar to Dean's proposal on
sending 200 OK already for early media (but it would not affect charging
models etc which are based on the assumption that 200 OK means that the
user has answered).
- The problem, as Dean said earlier, is of course that the one that the
entity that first starts to send early media (and 18x) may not be the
entity that would accept the call. But, since all other legs would be
terminated, the only entity which can accept the call is the one who
send 18x first.
Regards,
Christer
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip