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

From: [email-masked]
Date: Sun, 22 Oct 2006 18:50:01 -0400

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 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit 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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-service-examples-11.txt".
	
NOTE:	The mail server at 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Alan Johnston <[email-masked]>
Date: Mon, 23 Oct 2006 08:51:40 -0500

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:[email-masked]?Replaces=
 >        sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3
 >        %3Bfrom-tag%3D8675309>
 >
 > and it must be written as:
 >
 >       Refer-To: 
<sips:[email-masked]?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:[email-masked]>
 >                ;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.

[email-masked] wrote:
> ------------------------------------------------------------------------
>

---

From: Venkatesh <[email-masked]>
Date: Wed, 25 Oct 2006 11:16:05 -0700

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 <[email-masked]> wrote:
> <
> sips:[email-masked]?Replaces=sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309
> >
> >

---

From: Alan Johnston <[email-masked]>
Date: Wed, 25 Oct 2006 13:43:03 -0500

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:
> On 10/23/06, *Alan Johnston* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     All,
>
>     <http://sips:[email-masked]?Replaces=>
>     <http://sips:[email-masked]?Replaces=sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309>>
>     >
>     >       Contact: <sip:[email-masked] <mailto:sip:[email-masked]>>
>     >                ;q=.01
>     >
>     [email-masked] <mailto:[email-masked]> wrote:
>     > [email-masked]
>     <mailto:[email-masked]> 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>
>     >       [email-masked] <mailto:[email-masked]>.
>     > 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
>     > Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>     > Use [email-masked] <mailto:[email-masked]> for new developments of
>     core SIP
>
>
>     Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>     Use [email-masked] <mailto:[email-masked]> for new developments of
>     core SIP
>
>

---

From: Venkatesh <[email-masked]>
Date: Wed, 25 Oct 2006 12:07:15 -0700

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 <[email-masked]> wrote:
> http://sips:[email-masked]?Replaces=sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309
> >>
> >     >
> >     > Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Oct 2006 15:40:25 -0400

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* <[email-masked] 
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     All,
>      >
>      >     the SIP Service Examples I-D has been updated and is now
>     ready to
>      >     progress.
>      >
>      >     > Pickup) of draft-ietf-sipping-service-examples-10.txt .
>      >     >
>      >
>      >     >
>      >     > * Header line breaking
>      >     >
>      >     >       Refer-To: <
>     sips:[email-masked]?Replaces=
>     <http://sips:[email-masked]?Replaces=sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309>
>      >     <
>     http://sips:[email-masked]?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:[email-masked]
>     <mailto:sip:[email-masked]> <mailto:sip
>     <mailto:sip>:[email-masked] <mailto:[email-masked]>>>
>      >     >                ;q=.01
>      >     >
>      >     > Clearly, these long headers can't be represented directly
>     in the
>      >     I-D,
>      >     [email-masked] <mailto:[email-masked]>
>     <mailto: [email-masked] <mailto:[email-masked]>>
>     wrote:
>      >     >       Filename        :
>     draft-ietf-sipping-service-examples-11.txt
>      >     >       Pages           : 157
>      >     >       Date            : 2006-10-22
>      >     >
>     <http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-11.txt>
>      >     >
>     <mailto:[email-masked]>
>      >     <mailto: [email-masked]
>     <mailto:[email-masked]>> with the word unsubscribe
>      >     in the body of
>      >     > the message.
>      >     > You can also visit
>      >     >       [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>.
>      >     > In the body type:
>      >     >       "FILE
>      >     > NOTE: The mail server at ietf.org <http://ietf.org> <
>     http://ietf.org> can return
>      >     the document in
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>> for questions on current sip
>      >     > Use [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> for new developments of
>      >     core SIP
>      >
>      >
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>> for questions on current sip
>      >     Use [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> for new developments of
>      >     core SIP
>      >
>      >
> 
> 
>

---

From: "Mike Chack" <[email-masked]>
Date: Fri, 27 Oct 2006 10:29:10 -0700

Alan/Venkatesh:

I have a proposal that could work within the confines of the existing RFC's.  

Start with Venkatesh's proposal.  Party A, INVITEs w/o SDP towards the Media Server.  Instead of forwarding on the response directly to the target to be held (B), associate this dialog with a "pseudo" session at A.  A then refers/replaces B back to itself using the "pseudo" session, where it then completes the offer/answer negotiation, but this time in the context of a new session.   This gets past the limitations of current offer/answer restrictions and keeps A in the loop so call can be reestablished using similar mechanism.

This mechanism could be used for other 3PCC scenarios.

Mike

________________________________

From: Venkatesh [mailto:[email-masked]] 
Sent: Wednesday, October 25, 2006 12:07 PM
To: Alan Johnston
Cc: [email-masked]
Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-service-examples-11.txt

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

Hi Venkatesh,

Thanks,
Alan

Venkatesh wrote:
>     >       Refer-To: < sips:[email-masked]?Replaces= <http://sips:[email-masked]?Replaces=> 
>     < http://sips:[email-masked]?Replaces=sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309 <http://sips:[email-masked]?Replaces=sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309> >>
>     >
>     >       Contact: <sip:[email-masked] <mailto:sip:[email-masked] >>
>     >                ;q=.01
>     >
>     [email-masked] <mailto: [email-masked]> wrote:
>     <mailto: [email-masked]> with the word unsubscribe
>     in the body of
>     > the message.
>     > You can also visit
>     > NOTE: The mail server at ietf.org < http://ietf.org <http://ietf.org> > can return
>     the document in

---

From: Alan Johnston <[email-masked]>
Date: Fri, 27 Oct 2006 16:07:40 -0500

Hi Mike,

Thanks for your proposal. This call flow could certainly be reworked 
along these lines to use INVITE Replaces, or REFER. We had selected 3pcc 
instead because we thought it was simpler. We may use this approach if 
there isn't a simple fix to the 3pcc scenario.

Thanks,
Alan

Mike Chack wrote:
>
> Alan/Venkatesh:
>
> I have a proposal that could work within the confines of the existing 
> RFC’s.
>
> Start with Venkatesh’s proposal. Party A, INVITEs w/o SDP towards the 
> Media Server. Instead of forwarding on the response directly to the 
> target to be held (B), associate this dialog with a “pseudo” session 
> at A. A then refers/replaces B back to itself using the “pseudo” 
> session, where it then completes the offer/answer negotiation, but 
> this time in the context of a new session. This gets past the 
> limitations of current offer/answer restrictions and keeps A in the 
> loop so call can be reestablished using similar mechanism.
>
> *From:* Venkatesh [mailto:[email-masked]]
> *Sent:* Wednesday, October 25, 2006 12:07 PM
> *To:* Alan Johnston
> *Cc:* [email-masked]
> *Subject:* Re: [Sipping] I-D 
> ACTION:draft-ietf-sipping-service-examples-11.txt
>
> 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 
> behavior makes sense. For better or worse, there are implementations 
> 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* <[email-masked] 
> > > Refer-To: < sips:[email-masked]?Replaces= 
> > > Contact: <sip:[email-masked] <mailto:sip:[email-masked]> 
> <mailto:sip <mailto:sip>:[email-masked] <mailto:[email-masked]>>>
> > > ;q=.01
> > >
> > [email-masked] <mailto:[email-masked]> <mailto: 
> [email-masked] <mailto:[email-masked]>> wrote:
> > > [email-masked] <mailto:[email-masked]>