Re: [Sipping] I-D ACTION:draft-ietf-sipping-service-examples-11.txt

Venkatesh <vvenkatar@gmail.com> Wed, 25 October 2006 19:07 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gco5w-0002Y9-PI; Wed, 25 Oct 2006 15:07:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gco5u-0002XD-S5 for sipping@ietf.org; Wed, 25 Oct 2006 15:07:18 -0400
Received: from wx-out-0506.google.com ([66.249.82.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gco5r-0000V0-Ue for sipping@ietf.org; Wed, 25 Oct 2006 15:07:18 -0400
Received: by wx-out-0506.google.com with SMTP id t4so217119wxc for <sipping@ietf.org>; Wed, 25 Oct 2006 12:07:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=sdrVpA1kqoaJqK1CIsreK3Ps/lT9AcHMwuo79yC3T2PNx3cvVr+1nIr6m5batiKSRtwDbB2Qe0wgFx3+AFZJl2jKrCPr5CcRsiXvuhYxPufDdXGrLfpAtsJ5HziQzrJTj92+lipOERBt8yEr4OrTmxxTi6SX5avze4T88Um+Yjo=
Received: by 10.90.105.20 with SMTP id d20mr652411agc; Wed, 25 Oct 2006 12:07:15 -0700 (PDT)
Received: by 10.90.100.1 with HTTP; Wed, 25 Oct 2006 12:07:15 -0700 (PDT)
Message-ID: <4ff4e7370610251207k64a90d9bi301810b5017f097c@mail.gmail.com>
Date: Wed, 25 Oct 2006 12:07:15 -0700
From: Venkatesh <vvenkatar@gmail.com>
To: Alan Johnston <alan@sipstation.com>
Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-service-examples-11.txt
In-Reply-To: <453FB037.3000606@sipstation.com>
MIME-Version: 1.0
References: <E1Gbm8n-0006Qd-TN@stiedprstage1.ietf.org> <453CC8EC.1090303@sipstation.com> <4ff4e7370610251116w4d764541h5bdc18d5d3989f90@mail.gmail.com> <453FB037.3000606@sipstation.com>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: ce2737a971e141e0457c8c1bf182367f
Cc: sipping@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1878473969=="
Errors-To: sipping-bounces@ietf.org

Alan:

I agree that the draft/call flow you have indicated in the document for MOH
does not show dynamic pay load but based on experiences I have had with
various vendors, there are dynamic payloads involved in a majority of calls
thus making this example flow un-usable in most real world examples. I also
agree there needs to be a broader discussion w.r.t 3PCC and dynamic pay load
types. However, in the absence of such guidelines, I am not sure depicting
call flows that violates RFC 3264 behavior makes sense. For better or worse,
there are implementations that adhere to RFC 3264 and such a call flow would
break these implementations.

An alternate proposal to fix this call flow could be to initiate an INVITE
w/o SDP towards the 'held side' and use that as an offer towards the media
server. This would keep the call flow compliant with RFC 3264 regardless of
whether dynamic payloads are involved in the call or not.

Venkatesh

On 10/25/06, Alan Johnston <alan@sipstation.com> wrote:
>
> Hi Venkatesh,
>
> The message seems to talk about a general issue of dynamic payload types
> and 3pcc.  The call flow for MOH in this draft doesn't show dynamic
> payload types.  There isn't anything that relates to the Music on Hold
> service, right?
>
> Rather than a clarification in this examples draft, perhaps what we need
> is a general discussion about how a controller handles dynamic payload
> types in 3pcc, i.e. an update to RFC 3725.
>
> Thanks,
> Alan
>
> Venkatesh wrote:
> > Alan:
> >
> > I had raised a potential issue with MOH call flows in this draft. The
> > details of the issue can be found in this thread
> >  http://www1.ietf.org/mail-archive/web/sipping/current/msg11038.html .
> >
> > The problem is that the call flows depicted potentially violates the
> > offer/answer rules. I am not sure there is a clear resolution on the
> same.
> >
> > Thanks,
> > Venkatesh
> >
> >
> > On 10/23/06, *Alan Johnston* <alan@sipstation.com
> > <mailto:alan@sipstation.com>> wrote:
> >
> >     All,
> >
> >     Thanks to to the detailed comments and corrections from the
> reviewers,
> >     the SIP Service Examples I-D has been updated and is now ready to
> >     progress.
> >
> >     The only major change is the removal of the Single Line Extension
> call
> >     flow.  I am working with the authors of
> >     draft-anil-sipping-bla-03.txt on
> >     call flows for this feature in a separate I-D.
> >
> >     Thanks again to Vijay Gurbani, John Elwell, Joel Repiquet, Nagesh
> >     Kumar,
> >     Chandra Ravipati, Eric Burger, Jeroen Bemmel, Miguel Garcia, and
> Dale
> >     Worley.
> >
> >     Below are a few cases where I had some comments on the review.
> >
> >     Thanks,
> >     Alan
> >
> >     - - -
> >
> >     Joël Repiquet wrote:
> >
> >     >
> >     > 2.4.  Transfer - Unattended
> >     > ------------------------------
> >     >
> >     > 1) The "Supported: replaces" message-header line in F1, F3, F4,
> F11
> >     and F13
> >     >    is superfluous and I suggest to remove it
> >
> >     I have left the Supported header field in - it is a good idea to
> list
> >     supported features even if they are not being invoked at that time.
> >
> >
> >     nagesh kumar wrote:
> >     >
> >     > 2.7
> >     >
> >     > F3 - Here proxy sends 181 when it is forwarding the call. However,
> >     proxy shall not generate any response by itself as per RFC 3261 -
> >     P110.
> >     > "Since a proxy may not insert a tag into the To header field of
> >     a 1xx
> >     response to a request that did not contain one, it cannot issue
> >     > non-100 provisional responses on its own. "
> >
> >     I have added a clarification that the Server is acting as a UAS
> >     when it
> >     generates the 181 response.  I also included a To tag based on
> >     previous
> >     list discussion.
> >
> >     Dale R. Worley wrote:
> >     > Following is my review of sections 2.16 (Call Park) and 2.17 (Call
> >     > Pickup) of draft-ietf-sipping-service-examples-10.txt.
> >     >
> >
> >     >
> >     > * Header line breaking
> >     >
> >     > While the grammar of RFC 3261 section 25.1 allows header values
> >     to be
> >     > broken at most delimiters, it does not allow URIs to be
> >     broken.  (And
> >     > this is confirmed by the examples in RFC 3261.)  So this header is
> >     > invalid:
> >     >
> >     >       Refer-To: <sips:39itp34klkd@chicago.example.com?Replaces=
> >     <http://sips:39itp34klkd@chicago.example.com?Replaces=>
> >     >        sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3
> >     >        %3Bfrom-tag%3D8675309>
> >     >
> >     > and it must be written as:
> >     >
> >     >       Refer-To:
> >     <
> >
> sips:39itp34klkd@chicago.example.com?Replaces=sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309
> >     <
> http://sips:39itp34klkd@chicago.example.com?Replaces=sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309
> >>
> >     >
> >     > Note that "header parameters" on URIs can be broken, so this is
> >     valid:
> >     >
> >     >       Contact: <sip:foo@example.com <mailto:sip:foo@example.com>>
> >     >                ;q=.01
> >     >
> >     > Clearly, these long headers can't be represented directly in the
> >     I-D,
> >     > so we need some sort of line-breaking convention.  Perhaps
> >     something
> >     > like this could be added to section 1.1:
> >     >
> >     >     For publication, some headers must have line breaks inserted
> in
> >     >     locations that the grammar does not permit line breaks.  A
> line
> >     >     that is presented here as ending with "<<br>>" should be
> >     >     interpreted by removing that string, the following line
> >     break, and
> >     >     any leading whitespace on the next line.
> >     >
> >     > The locations I've discovered that need this treatment would then
> be
> >     > presented as follows:
> >     >
> >     > Section 2.5:
> >     >
> >     >       F15 REFER Bob -> Alice
> >     >
> >     >
> >
> >     I have fixed this by using the <allOneLine> tag defined in RFC 4475.
> >
> >     Internet-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org> wrote:
> >     > A New Internet-Draft is available from the on-line Internet-Drafts
> >     > directories.
> >     > This draft is a work item of the Session Initiation Proposal
> >     Investigation Working Group of the IETF.
> >     >
> >     >       Title           : Session Initiation Protocol Service
> Examples
> >     >       Author(s)       : A. Johnston, et al.
> >     >       Filename        : draft-ietf-sipping-service-examples-11.txt
> >     >       Pages           : 157
> >     >       Date            : 2006-10-22
> >     >
> >     > This document gives examples of Session Initiation Protocol (SIP)
> >     >    services.  This covers most features offered in so-called IP
> >     Centrex
> >     >    offerings from local exchange carriers and PBX (Private Branch
> >     >    Exchange) features.  Most of the services shown in this
> >     document are
> >     >    implemented in the SIP User Agents, although some require the
> >     >    assistance of a SIP Proxy.  Some require some extensions to SIP
> >     >    including the REFER, SUBSCRIBE, and NOTIFY methods and the
> >     Replaces
> >     >    and Join headers.  These features are not intended to be an
> >     >    exhaustive set, but rather show implementations of common
> >     features
> >     >    likely to be implemented on SIP IP telephones in a business
> >     >    environment.
> >     >
> >     > A URL for this Internet-Draft is:
> >     >
> >
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-11.txt
> >     >
> >     > To remove yourself from the I-D Announcement list, send a message
> to
> >     > i-d-announce-request@ietf.org
> >     <mailto:i-d-announce-request@ietf.org> with the word unsubscribe
> >     in the body of
> >     > the message.
> >     > You can also visit
> >     https://www1.ietf.org/mailman/listinfo/I-D-announce
> >     <https://www1.ietf.org/mailman/listinfo/I-D-announce>
> >     > to change your subscription settings.
> >     >
> >     > Internet-Drafts are also available by anonymous FTP. Login with
> the
> >     > username "anonymous" and a password of your e-mail address. After
> >     > logging in, type "cd internet-drafts" and then
> >     > "get draft-ietf-sipping-service-examples-11.txt".
> >     >
> >     > A list of Internet-Drafts directories can be found in
> >     > http://www.ietf.org/shadow.html
> >     > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >     >
> >     > Internet-Drafts can also be obtained by e-mail.
> >     >
> >     > Send a message to:
> >     >       mailserv@ietf.org <mailto:mailserv@ietf.org>.
> >     > In the body type:
> >     >       "FILE
> >     /internet-drafts/draft-ietf-sipping-service-examples-11.txt".
> >     >
> >     > NOTE: The mail server at ietf.org <http://ietf.org> can return
> >     the document in
> >     >       MIME-encoded form by using the "mpack" utility.  To use this
> >     >       feature, insert the command "ENCODING mime" before the
> "FILE"
> >     >       command.  To decode the response(s), you will need
> >     "munpack" or
> >     >       a MIME-compliant mail reader.  Different MIME-compliant
> >     mail readers
> >     >       exhibit different behavior, especially when dealing with
> >     >       "multipart" MIME messages (i.e. documents which have been
> >     split
> >     >       up into multiple messages), so check your local
> >     documentation on
> >     >       how to manipulate these messages.
> >     >
> >     > Below is the data which will enable a MIME compliant mail reader
> >     > implementation to automatically retrieve the ASCII version of the
> >     > Internet-Draft.
> >     >
> >     >
> >
> ------------------------------------------------------------------------
> >
> >     >
> >     > _______________________________________________
> >     > Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping
> >     > This list is for NEW development of the application of SIP
> >     > Use sip-implementors@cs.columbia.edu
> >     <mailto:sip-implementors@cs.columbia.edu> for questions on current
> sip
> >     > Use sip@ietf.org <mailto:sip@ietf.org> for new developments of
> >     core SIP
> >
> >
> >     _______________________________________________
> >     Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> >     This list is for NEW development of the application of SIP
> >     Use sip-implementors@cs.columbia.edu
> >     <mailto:sip-implementors@cs.columbia.edu> for questions on current
> sip
> >     Use sip@ietf.org <mailto:sip@ietf.org> for new developments of
> >     core SIP
> >
> >
>
>
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP