Subject: RE: [Sipping] Last Call: draft-ietf-sipping-service-examples to B CP

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 13 Nov 2007 16:28:38 +0000

I have some comments below on Paul's response to my comments.

Paul Kyzivat wrote:
> 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. 

On the whole I agree with Paul's statement that there may be occasions when
"a=sendonly" could be used even if no media is to be sent. However IMHO
"a=sendonly" is commonly misused both by SIP Clients and some SIP Servers
which interpret "a=sendonly" as meaning "call hold" when it really only
means that the sender wishes to send and not receive media and to be honest
the draft-ietf-sipping-service-examples is one of the causes of this
problem.

Regards
Andy

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 12 November 2007 23:33
> To: Hutton, Andrew; [email-masked]'
> Subject: Re: [Sipping] Last Call: 
> draft-ietf-sipping-service-examples to BCP
> 
> 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.
> 
> 
> Hutton, Andrew wrote:
> > 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.
> 
> 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
> 
> 
> > 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
> > 
> 

_______________________________________________
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