Subject: [salud] Sections 9 and 10

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 15 Mar 2012 17:47:29 -0400

I'm looking at sections 9 and 10, "User Agent Behavior" and "Proxy
Behavior".  I think that the statements about "disturbing
interference" need to be limited to requirements on the receiver of
the Alert-Info, because there is no way that the sender can be sure
what might cause the receiver to produce a disturbing rendering.  So I
think we can improve the wording in the following way:

   9.  User Agent Behaviour

   [-05 text:]
   A SIP UA MAY add a URN or multiple URNs to the Alert-Info header
   field in a SIP request or a provisional 1xx response excepting 100
   response when it needs to provide additional information about the
   call or about the provided service.  A SIP UA SHOULD NOT add a
   mixture of Alert-Info URNs and URIs to the Alert-Info header field
   that may cause disturbing rendering interference at the recipient's
   User Agent (UA).

      [suggested replacement:]
      A SIP UA MAY add a URN or multiple URNs to the Alert-Info header
      field in a SIP request or a provisional 1xx response (excepting a 100
      response) when it needs to (wishes to?) provide additional
      information about the call or about the provided service.

   [-05 text:]
   Upon receiving a SIP INVITE request or a SIP provisional response
   with an Alert-Info header field that contains a combination of Alert-
   Info URNs, the User Agent (UA) attempts to match the received Alert-
   Info URNs combination with a signal it can render.  The mandatory
   rules and an non-normative algorythm example are described in
   Section 7 and Section 8.  The User Agent (UA) ignores the Alert-Info
   URNs for which no match is found and proceeds with the normal
   operation.

      [suggested replacement:]
      Upon receiving a SIP INVITE request or a SIP provisional response
      with an Alert-Info header field that contains a combination of Alert-
      Info URNs, the User Agent (UA) attempts to match the received Alert-
      Info URNs combination with a signal it can render.  The process
      the UA uses MUST conform to the rules described in Section 7.
      (A non-normative algorithm example for the process is described
      in Section 8.)

         [discussion:]
	 I've omitted the sentence "... ignores the Alert-Info URNs
	 form which no match ...", because that is already stated in
	 rule (b) in Section 7.

   [-05 text:]
   The User Agent (UA) is responsible for the non disturbing rendering
   if multiple indications and network resources are to be rendered
   simultaneously.

      [suggested replacement:]
      The User Agent (UA) is responsible for producing a reasonable
      rendering regardless of the combination of URIs (of any schemes)
      in the Alert-Info header field.

         [discussion:]
	 This places the burden on the receiver not to produce a
	 disturbing rendering regardless of the Alert-Info header
	 values.

   10.  Proxy Behaviour

   [-05 text:]
   A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header
   field in a SIP request or a provisional 1xx response excepting 100
   response when it needs to provide additional information about the
   call or about the provided service.  A SIP Proxy SHOULD NOT add a
   mixture of Alert-Info URNs and URIs to the Alert-Info header field
   that may cause disturbing rendering interference at the recipient's
   User Agent (UA).

      [suggested replacement:]
      A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header
      field in a SIP request or a provisional 1xx response (excepting a 100
      response) when it needs to (wishes to?) provide additional
      information about the call or about the provided service.

         [discussion:]
	 Similarly, I don't think there is a way that a proxy can tell
	 what might cause a problem for a UA.  So we have to allow the
	 proxy to do anything.

   [-05 text:]
   Following example shows both the network audio resource referenced by
   the HTTP URI and the URN indication for the call-waiting service
   transported by the Alert-Info header field in a 180 Ringing
   provisional response.

   [-05 text:]
      Alert-Info: <http://www.example.com/sound/moo.wav>,
       <urn:alert:service:call-waiting>

      [suggested replacement:]
	 SIP/2.0 180 Ringing
	 Alert-Info: <http://www.example.com/sound/moo.wav>,
	    <urn:alert:service:call-waiting>
	 To: Bob <sip:[email-masked]>;tag=a6c85cf
	 From: Alice <sip:[email-masked]>;tag=1928301774
	 Call-ID: a84b4c76e66710
	 Contact: <sip:[email-masked]>
	 CSeq: 314159 INVITE
	 Via: SIP/2.0/UDP server10.biloxi.example.com;branch=z9hG4bK4b43c2ff8.1
	 Content-Length: 0

         [discussion:]
	 I stole an examle 180 Ringing response from RFC 3261 and
	 inserted the Alert-Info example into it so that the reader
	 can see a complete SIP response with Alert-Info.

	 Some might consider "moo.wav" as a "disturbing" rendering of
	 a ringback tone!  ;-)

Dale

---

From: Laura Liess <[email-masked]>
Date: Mon, 19 Mar 2012 10:35:33 +0100

Dale,
I agree with your comments.

  >         disturbing rendering regardless of the Alert-Info header
It is very reasonable to do this also because there may be more than
one entities inserting Alert-Info URNs. Requiring that a proxy in the
path adding an Alert-Info URN has to inspect all other URNs in the
header in order to avoid disturbing rendering would be a quite high
burden for the proxy.

Thanks
Laura

2012/3/15 Worley, Dale R (Dale) <[email-masked]>:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud