[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Early media as an endpoint application
On Aug 23, 2008, at 6:12 AM, Christer Holmberg wrote:
>>
>>
>> Would these services be impossible if there were actually separate
>> SIP
>> sessions for the "early" and "regular" sessions?
>
> Maybe not, but I am still not sure what problems you would solve by
> having separate sessions.
By having a fully connected "offer/answer" completed session instead
of "early session", we escape most of the state machine complexities,
resolve the "media before answer" pinhole opening and codec loading
problem, etc. It also makes ICE and SRTP much easier to deal with. By
making the transition to "regular" session a re-invite the gateway
can transition from send-only to send-receive (if needed), the billing
system (if it cares) can start the meter running, etc.
Plus we can drop all the 100-rel and preconditions cruft out of the
state machine completely, making life MUCH better for the coder.
Think of it this way -- If I'm calling a PSTN gateway, do I really
want to wait until the PSTN side connection completes before I do the
setup work for SRTP? I think I'd rather get that out oFrom sip-bounces at ietf.org Sat Aug 23 21:07:31 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9BCF63A6A2A;
Sat, 23 Aug 2008 21:07:31 -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 26F6D28C0FF
for <sip at core3.amsl.com>; Sat, 23 Aug 2008 21:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5
tests=[BAYES_50=0.001]
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 5JRCRmlAcAow for <sip at core3.amsl.com>;
Sat, 23 Aug 2008 21:07:29 -0700 (PDT)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164])
by core3.amsl.com (Postfix) with ESMTP id ABA783A69B7
for <sip at ietf.org>; Sat, 23 Aug 2008 21:07:29 -0700 (PDT)
Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com
[76.185.142.113]) (authenticated bits=0)
by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
m7O46vOu019936
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
Sat, 23 Aug 2008 23:06:58 -0500
Message-Id: <25AEB4FF-0DD7-4F69-98D8-F02B0CC794C3 at softarmor.com>
From: Dean Willis <dean.willis at softarmor.com>
To: Christer Holmberg <christer.holmberg at ericsson.com>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF046C7916 at esealmw113.eemea.ericsson.se>
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Sat, 23 Aug 2008 23:06:52 -0500
References: <16BE241A-8699-485A-A450-BD27AA2EFAE6 at softarmor.com><C4D2F10C.7CB9%hsinnrei at adobe.com><092B2658AAB56A4D80836399A4C4703105E30A9C at ASHEVS002.mcilink.com><B328D2F6-AE16-40CB-B4AE-5BD59CFA5F7D at softarmor.com><092B2658AAB56A4D80836399A4C4703105B7C626 at ASHEVS002.mcilink.com>
<68BCCF24-16B2-499C-A4FC-3EF5A760C150 at softarmor.com>
<CA9998CD4A020D418654FCDEF4E707DF0791B681 at esealmw113.eemea.ericsson.se>
<865BA838-48F9-453C-AD11-0AF49BA9FD79 at softarmor.com>
<CA9998CD4A020D418654FCDEF4E707DF046C7916 at esealmw113.eemea.ericsson.se>
X-Mailer: Apple Mail (2.928.1)
Cc: SIP IETF <sip at ietf.org>
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
On Aug 23, 2008, at 6:12 AM, Christer Holmberg wrote:
>>
>>
>> Would these services be impossible if there were actually separate
>> SIP
>> sessions for the "early" and "regular" sessions?
>
> Maybe not, but I am still not sure what problems you would solve by
> having separate sessions.
By having a fully connected "offer/answer" completed session instead
of "early session", we escape most of the state machine complexities,
resolve the "media before answer" pinhole opening and codec loading
problem, etc. It also makes ICE and SRTP much easier to deal with. By
making the transition to "regular" session a re-invite the gateway
can transition from send-only to send-receive (if needed), the billing
system (if it cares) can start the meter running, etc.
Plus we can drop all the 100-rel and preconditions cruft out of the
state machine completely, making life MUCH better for the coder.
Think of it this way -- If I'm calling a PSTN gateway, do I really
want to wait until the PSTN side connection completes before I do the
setup work for SRTP? I think I'd rather get that out of the waf the way before
the called party answers, or before I even see early media coming back
unprotected.
Now, lets think about forking. When we fork in a proxy, the UAC can
only deal with one "best answer", and early media is anybody's guess
as to how it might work or what might happen (it pretty much turns to
soup, especially if you get multiple early media channels).
Consider instead that a forking node is really a "forking gateway",
not a proxy. It takes one call in, establishes a fully-negotiated
"early session", then sends out its multiple INVITES. As those
sessions (which might have early media) connect up, the forking
gateway deals with the multiple media streams (by bridging,
discarding, whatever). When a forked session matures to a "regular
session", the forking gateway can re-invite the UAC to make that
session a "regular session", or can even arrange to drop itself out of
the media path if needed.
If we have to have forking, and we have to have media before there's a
final answer, then I think something like this is needed to make it
work.
--
Dean
_______________________________________________
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
y before
the called party answers, or before I even see early media coming back
unprotected.
Now, lets think about forking. When we fork in a proxy, the UAC can
only deal with one "best answer", and early media is anybody's guess
as to how it might work or what might happen (it pretty much turns to
soup, especially if you get multiple early media channels).
Consider instead that a forking node is really a "forking gateway",
not a proxy. It takes one call in, establishes a fully-negotiated
"early session", then sends out its multiple INVITES. As those
sessions (which might have early media) connect up, the forking
gateway deals with the multiple media streams (by bridging,
discarding, whatever). When a forked session matures to a "regular
session", the forking gateway can re-invite the UAC to make that
session a "regular session", or can even arrange to drop itself out of
the media path if needed.
If we have to have forking, and we have to have media before there's a
final answer, then I think something like this is needed to make it
work.
--
Dean
_______________________________________________
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