Subject: RE: [Sipping] Last Call: draft-ietf-sipping-service-examples (Ses sion Initiation Protocol Service Examples) to BCP

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 09 Nov 2007 09:39:28 +0000

Whilst the document contains some useful examples of how services might be
implemented it does not I believe represent the BCP for some services and
publishing this as BCP may not help interoperability.

For example the document describes the service "Call Hold" and indicates
that "a=sendonly" should be used but also states that "a UA that places the
other party on hold will generally also stop sending media, resulting in no
media exchange between the Uas".

The use of "a=sendonly" in the case where no media is to be sent is clearly
not best practice as in this case "a=inactive" should be used. 

The draft-ietf-sipping-sip-offeranswer contains a much better description of
how media should be held and resumed.

Regards
Andy

However,   Older UAs may set the
   connection address to 0.0.0.0 when initiating hold.  However, this
   behavior has been deprecated in favor of using the a=sendonly SDP
   attribute.

> -----Original Message-----
> From: The IESG [mailto:[email-masked]] 
> Sent: 08 November 2007 13:42
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [Sipping] Last Call: 
> draft-ietf-sipping-service-examples (Session Initiation 
> Protocol Service Examples) to BCP
> 
> The IESG has received a request from the Session Initiation Proposal 
> Investigation WG (sipping) to consider the following document:
> 
> - 'Session Initiation Protocol Service Examples '
>    <draft-ietf-sipping-service-examples-13.txt> as a BCP
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive 
> comments to the
> [email-masked] mailing lists by 2007-11-22. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
>
http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-
13.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=8508&rfc_flag=0
> 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Nov 2007 18:32:33 -0500

When I saw this reply I decided to take a look for the first time in a 
long time. First I have a reply to Andrew and then I have a couple of 
comments of my own. See inline.

> how media should be held and resumed.

I wrote the description of hold in the offeranswer draft. But I won't go 
so far as to say inactive SHOULD be used when no media is to be sent. 
What I said was "may", and it think that is more appropriate.

Using sendonly when you don't intend to send anything is still of *some* 
value in reducing possible clipping when going off hold. If you go off 
hold when you had sendonly you can immediately start sending the media 
which could be good if your user starts talking right away. If inactive 
had been negotiated then you must wait for another o/a exchange before 
you can start sending.

OTOH, inactive may allow some media paths to give up QoS and save some 
resources. Relative merits depend on your priorities and other specifics 
of your situation. The key thing is that the holdee must be *prepared* 
to handle either.

2.13 Call Management (Incoming Call Screening)

In F4 I question why there isn't a Route header identifying the proxy. 
While its legal to sent the request to the proxy without the route 
header, IMO using it is preferred.

There are of course issues around use of 305 because its meaning is 
under specified. Jonathan wrote a draft addressing that but its still 
stuck somewhere. But its not so ambiguous in this particular case.

2.15 Call Park

This call flow is a little unbelievable. It is a leap of faith that 
Carol can get the dialog info from Bob to pick up the call. Its not the 
kind of info that can be yelled across a wall - it needs to be 
communicated in some kind of signaling message, so that ought to be 
shown in the call flow.

Of course there are a lot of ways to do that, and they can't all be 
shown. But I think one needs to be picked for the example. For instance 
Carol could send an ordinary invite to the Park Server, and it could 
proxy it, including the replaces header.

	Thanks,
	Paul