Re: [Sip] Doubts in SIP/SDP

Dean Willis <dean.willis@softarmor.com> Thu, 09 December 2004 22:45 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23932 for <sip-web-archive@ietf.org>; Thu, 9 Dec 2004 17:45:44 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcX9k-0004kB-N6 for sip-web-archive@ietf.org; Thu, 09 Dec 2004 17:53:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcWxS-0004Fo-Nr; Thu, 09 Dec 2004 17:40:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcWol-0000Kn-QD for sip@megatron.ietf.org; Thu, 09 Dec 2004 17:31:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22614 for <sip@ietf.org>; Thu, 9 Dec 2004 17:31:21 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcWvp-0004Lv-PI for sip@ietf.org; Thu, 09 Dec 2004 17:38:42 -0500
Received: from [10.10.10.141] (pool-138-89-35-120.mad.east.verizon.net [138.89.35.120]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iB9MVx4L031647 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Dec 2004 16:32:03 -0600
In-Reply-To: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FFF@hadron.jnpr.net>
References: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FFF@hadron.jnpr.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <08427279-4A32-11D9-BBA2-000D93594350@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Doubts in SIP/SDP
Date: Thu, 09 Dec 2004 16:31:13 -0600
To: Anil Bollineni <ABollineni@juniper.net>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit

BTW, this is a lovely "sip-implementors" list question.

Answers herein are my opinion, and may not mesh with some particularly 
strict interpretations. On the other hand, one can refer to the Postel 
axiom "be liberal with what you accept" (or however he said that . . .)

More detailed procedures are available in 
draft-ietf-sipping-early-media-02.txt, which I believe has been 
approved by the IESG and is in the RFC Editor queue.

On Dec 7, 2004, at 6:10 PM, Anil Bollineni wrote:

> Hi,
>   Thanks for the response. I have a basic question, considering 3 
> views.
>
> 1. Suppose terminating endpoint does not support 183, and sends the
> early media for IVR, should  UAC, play the media treated as if early
> media.
>

yes.

> 2. Any case the terminating endpoint must support 183 and send the 
> media
> after it sends. The 100rel is optional, in this case the sequence of 
> 183
> and early media is not guaranteed. Should UAC prepare media 
> irrespective
> of call progress message?
>

The UAC should play any media it receives that is consistent with the 
SDP it offered in the INVITE.

The exception to this case is described in the early media draft:

         Note that, in some situations, the UAC does need to receive
         the answer before being able to play any media. UAs in such
         a situation (e.g., QoS, media authorization or media
         encryption is required) use preconditions to avoid media
         clipping.

The use of preconditions is discussed in RFC 3312.

> 3. In case of 100Rel calling UA requires the option 100rel, should
> terminating endpoint MUST send always after PRACK is received?
>

That's debatable. One might be inclined to suspect that the calling UA 
has issues with "really early media" in this case, and the UAS SHOULD 
hold off until receiving the PRACK. I don't know that MUST applies, as 
one can reasonably expect that SOME UASs might not delay, so the 
calling UA MUST be prepared to deal with the consequences of a called 
UA that responds with media before sending an SDP answer.



> Specifically, if we want deploy a firewall between originating and
> terminating endpoints, should we allow early media after INVITE without
> 183 is being seen?
>

yes.


--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip