Venkatesh wrote:
> 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.

The example as it stands doesn't violate anything.

I gather your issue isn't that this example is wrong, but rather that it 
isn't realistic, and that if it were made realistic then it would be 
apparent that it would be likely to be wrong. Is that right?

So you would like to see everybody using dynamic payloads in this example?

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

That *might* produce better results. There are two potential issues with it:
- Once the response to the invite is received from the held side,
   there is a timer limiting how long the invite to the music server
   can take. This might be ok since the server is an automaton that
   will normally answer immediately, but it is at least a small concern.

- even if there is no problem with the timing, there is still a chance
   that 3264 will be violated due to information not available to the
   music server. 3264 requires that once a payload number has been used
   in a call (by one side) that it never be used to represent a different
   payload. The music server may get this wrong because it doesn't know
   what payload numbers have been used by Bob up to this time. Any
   assignment of codec to payload number may conflict with something that
   Bob has used previously with Alice.

The only reasonable solution to this is to relax the rules of 3264.

	Paul

> Venkatesh
>  
> On 10/25/06, *Alan Johnston* <alan@sipstation.com 
> <mailto: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>
>      > <mailto: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=>
>      >     <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>
>      >     <
>     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> <mailto:sip
>     <mailto:sip>:foo@example.com <mailto: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>
>     <mailto: 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
>     <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>
>      >     <mailto: 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>
>     <mailto: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> <
>     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>
>      >     <mailto:sip-implementors@cs.columbia.edu
>     <mailto:sip-implementors@cs.columbia.edu>> for questions on current sip
>      >     > Use sip@ietf.org <mailto:sip@ietf.org> <mailto: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>
>      >     <mailto:sip-implementors@cs.columbia.edu
>     <mailto:sip-implementors@cs.columbia.edu>> for questions on current sip
>      >     Use sip@ietf.org <mailto:sip@ietf.org> <mailto: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

_______________________________________________
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