Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02)

From: <[email-masked]>
Date: Thu, 13 May 2010 04:05:24 +0200

Dear all,
I have asked for comments on the two drafts mentioned below.
So far I didn't get any. Does that mean that people are happy now with the content and we could proceed with it?

Thank you and Best Regrads

Roland

> _____________________________________________ 
> Von: 	Jesske, Roland  
> Gesendet:	Donnerstag, 8. April 2010 09:46
> An:	[email-masked]
> Betreff:	Reason In responses (draft-jesske-dispatch-reason-in-responses-02)
> 
> Dear all,
> During the discussion concerning the Reason header field in Responses I was asked to split the document into an requirements part and an protocol part.
> So please feel free to comment on the drafts. 
> 
> http://64.170.98.42/html/draft-jesske-dispatch-reason-in-responses-02
> 
> http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-responses-00
> 
> Best regards
> 
> Roland Jesske
> 
> 
> Deutsche Telekom Netzproduktion GmbH
> Zentrum Technik Einführung
> Roland Jesske
> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
> +49 6151 628-2766 (Tel.)
> +49 521 9210-3753  (Fax)
> +49 171 8618-445  (Mobil)
> E-Mail: [email-masked]
> www.telekom.com  
> 
> Erleben, was verbindet. 
> 
> Deutsche Telekom Netzproduktion GmbH
> Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
> Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
> Handelsregister: Amtsgericht Bonn HRB 14190
> Sitz der Gesellschaft: Bonn
> USt-IdNr. DE 814645262
> 
> Große Veränderungen fangen klein an > ->  Ressourcen schonen und nicht jede E-Mail drucken.
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 May 2010 09:23:33 +0200

Roland,

In my view, there is a simple requirement to convey Q.850 causes in SIP response messages, so that the UAC will receive a more accurate indication of the reason for rejection when rejection comes from PSTN. The cause mapping table helps to illustrate this. This is not rocket science, and I am disappointed that we have not found a quick way of dispatching this and just getting the work done. In my opinion the split into separate documents was unnecessary (take as an example the recently-published RFC 5876, which combines motivation and solution in one document), but it has been done now. Unfortunately I don't think it has moved us any further forward.

I don't think the requirements in section 3 are particularly well expressed. REQ-1 can already be met by tunnelling in accordance with SIP-T. I would not expect the IETF to provide a new solution specifically for that requirement.

I think REQ-2 and REQ-3 boil down to the same thing - it must be possible to provide an accurate indication to a UAC, so that the UAC can provide a suitable indication to the user. Whether this be an announcement, a textual message, an icon, a flashing lamp, a tone, a vibration, an odour or whatever, is a user interface matter.

I also find REQ-4 rather problematic. If we have a solution for PSTN, we would also have a solution for some other form of gateway into a domain that provides a "PSTN-like service". Unfortunately, if you try to bring this out as a separate requirement, it raises the question of what exactly is this "PSTN-like service", and if it is somehow SIP-based, why it needs to be "PSTN-like", and so on.

Basically I think there is only a single requirement here - provision of a correct indication to a UAC when rejection comes from the PSTN. I think that is a reasonable requirement and we should just go ahead and do it, rather like we did with RFC 5876 when we extended the range of messages that PAI/PPI could be used in.

I find the statement in REQ-3 "A inclusion of [Q.850] causes is out of scope." very strange. I thought the whole idea was to convey Q.850 causes, so why say they are out of scope? I assume this is some sort of typo.

I think one of the consequences of deciding to split requirements and solution into separate drafts is that the requirements draft has to stick to motivation and requirements. I find too much in the draft (particularly the examples) that smells of solution.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 13 May 2010 03:05
> To: [email-masked]
> Subject: Re: [dispatch] Reason In responses 
> (draft-jesske-dispatch-reason-in-responses-02)
> 
> Dear all, 
> So far I didn't get any. Does that mean that people are happy 
> now with the content and we could proceed with it? 
> 
> Betreff:        Reason In responses 
> (draft-jesske-dispatch-reason-in-responses-02) 
> 
> Dear all, 
> During the discussion concerning the Reason header field in 
> Responses I was asked to split the document into an 
> requirements part and an protocol part.
> 
> <http://64.170.98.42/html/draft-jesske-dispatch-reason-in-resp
> onses-02>  
> 
> <http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-
> responses-00>  
> 
> Best regards 
> 
> Roland Jesske 
> 
> 
> E-Mail: [email-masked] <mailto:[email-masked]>  
> www.telekom.com <http:www.telekom.com>   
> 
> Erleben, was verbindet. 
> 
> Große Veränderungen fangen klein an - Ressourcen schonen und 
> nicht jede E-Mail drucken. 
> 
> 
>

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 13 May 2010 09:50:39 +0200

Elwell, John wrote:
> Basically I think there is only a single requirement here - provision
> of a correct indication to a UAC when rejection comes from the PSTN.
> I think that is a reasonable requirement and we should just go ahead
> and do it, rather like we did with RFC 5876 when we extended the
> range of messages that PAI/PPI could be used in.

Speaking as a service provider, that is indeed what is really needed.
The req draft does a decent job at framing it, maybe with a little too
much IMS-speak. That said, can we move on and try to agree on simple
solution for such a simple problem?

-- 
Ciao,
Enrico

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 May 2010 09:48:18 -0400

Hi Roland,
I wasn't sure if you were still planning on moving forward with this draft, given the Alert-Info URN draft.  I thought maybe instead you were going to define a mapping of Q.850 response codes to "semantic" URNs.  So since you're not, can you put some text in your draft (or email) why not, and what this Reason header in responses would be used for compared to Alert-Info?  I think it may help implementers to know what's what.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Wednesday, May 12, 2010 10:05 PM
> 
> Dear all,

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Thu, 13 May 2010 10:21:32 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Enrico Marocco [[email-masked]]

_______________________________________

I am more of a "SIP bigot", but if the response is ultimately due to a PSTN (SS7) operation, the Q.850 form of the Reason header seems an excellent way of recording the SS7 response code.  As John said, this can be legitimated very simply.  And I expect many implementors think it is already valid and are doing so.

Dale

---

From: Laura Liess <[email-masked]>
Date: Thu, 13 May 2010 21:09:22 +0200

Hadriel,

Alert-Info URNs and Reason in responses are two different things. 
Alert-Info URNs are names for ring tones which has to be rendered to the
users. They can be carried in INVITE or 18x responses and resolved by SIP
end devices according to local rules into a specific tones or text. They are
not involved in applications logic neither in SIP nor in PSTN.   

Reason in responses is about extending the usage of the Reason header
defined in RFC3326 to SIP responses. The RFC 3326 currently allows it only
in SIP requests. Typical use cases are to carry it in CANCEL or BYE requests
(see 3326 message flows) or in error responses. A typical message flows for
Reason in responses is shown in an earlier version of Roland's draft, e.g.
http://tools.ietf.org/id/draft-jesske-sipping-etsi-ngn-reason-04.txt, where
the reason is sent in 603 Decline. You can't do this with the Alert-Info
header.

Thanks,
Laura

-----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im
> Auftrag von Hadriel Kaplan
> Gesendet: Donnerstag, 13. Mai 2010 15:48
> An: [email-masked]; [email-masked]
> Betreff: Re: [dispatch] Reason In responses (draft-jesske-dispatch-
> reason-in-responses-02)
> 
> 
> Hi Roland,
> I wasn't sure if you were still planning on moving forward with this
> draft, given the Alert-Info URN draft.  I thought maybe instead you were
> going to define a mapping of Q.850 response codes to "semantic" URNs.  So
> since you're not, can you put some text in your draft (or email) why not,
> and what this Reason header in responses would be used for compared to
> Alert-Info?  I think it may help implementers to know what's what.
> 
> -hadriel
> 
> > So far I didn't get any. Does that mean that people are happy now with
> the
> > content and we could proceed with it?
> >
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 May 2010 19:39:26 -0400

Hi Laura,
Just to be clear: I'm fine with having both Alert-Info "semantic" URNs and Reason-header codes in responses.  I'm just asking that the drafts explain in their text why they are necessary to be separate, what they're used for that's "different", etc.  Basically, I'm trying to avoid confusion for implementers and operators if both of these become RFCs.

> From: Laura Liess [mailto:[email-masked]]
> Sent: Thursday, May 13, 2010 3:09 PM
> To: Hadriel Kaplan; [email-masked]; [email-masked]
> 

Well, to be nit-picky the proposed Alert-Info URN *is* involved in application logic in SIP: application logic to resolve a URN, render a tone, display a message, or whatever.  And in theory I assumed that if a PSTN SIT-signal was received on a PSTN-SIP gateway, it would convert it to an Alert-Info URN like "short-long-long"; and if that SIP response message hit another SIP-PSTN gateway to go back into PSTN, that it would convert it back to a SIT.  So it applies to that SIP-PSTN inter-working application logic as well.

So I suppose one question would be what _other_ logic a SIP UA or SIP-PSTN gateway would be doing with a Q.850 Reason-header cause-code that it couldn't be doing with a "semantic" Alert-Info URN which represented a cause-code. 

BTW, in the PSTN aren't those Q.850 codes also used for "rendering"?  Doesn't the PSTN-switch or PBX getting the response code use the Q.850 code to pick a specific tone sequence to play to a handset in some cases?

> the reason is sent in 603 Decline. You can't do this with the Alert-Info

I would think you'd want Alert-Info to apply to such failure responses too, no?  For example, there is a different tone presented today for a user-busy, vs. an all-circuits-busy, vs. an incorrect number.

Or do you mean an Alert-Info URN would only be used for rendering decisions of 18x, and a Reason-header would be used for rendering decisions of other SIP responses?

-hadriel

---

From: Laura Liess <[email-masked]>
Date: Fri, 14 May 2010 07:35:46 +0200

Hi Hadriel,
I am fine with this. 

Laura

> Von: Hadriel Kaplan [mailto:[email-masked]]
> Gesendet: Freitag, 14. Mai 2010 01:39
> An: Laura Liess; [email-masked]; [email-masked]
> Betreff: RE: [dispatch] Reason In responses (draft-jesske-dispatch-
> reason-in-responses-02)
> 
> 
> Hi Laura,
> Just to be clear: I'm fine with having both Alert-Info "semantic" URNs
> and Reason-header codes in responses.  I'm just asking that the drafts
> explain in their text why they are necessary to be separate, what they're
> used for that's "different", etc.  Basically, I'm trying to avoid
> confusion for implementers and operators if both of these become RFCs.
> 
> 
> > end devices according to local rules into a specific tones or text.
> They
> > are
> Well, to be nit-picky the proposed Alert-Info URN *is* involved in
> application logic in SIP: application logic to resolve a URN, render a
> tone, display a message, or whatever.  And in theory I assumed that if a
> PSTN SIT-signal was received on a PSTN-SIP gateway, it would convert it
> to an Alert-Info URN like "short-long-long"; and if that SIP response
> message hit another SIP-PSTN gateway to go back into PSTN, that it would
> convert it back to a SIT.  So it applies to that SIP-PSTN inter-working
> application logic as well.
> 
> So I suppose one question would be what _other_ logic a SIP UA or SIP-
> PSTN gateway would be doing with a Q.850 Reason-header cause-code that it
> couldn't be doing with a "semantic" Alert-Info URN which represented a
> cause-code.
> 
> BTW, in the PSTN aren't those Q.850 codes also used for "rendering"?
> Doesn't the PSTN-switch or PBX getting the response code use the Q.850
> code to pick a specific tone sequence to play to a handset in some cases?
> 
> 
> I would think you'd want Alert-Info to apply to such failure responses
> too, no?  For example, there is a different tone presented today for a
> user-busy, vs. an all-circuits-busy, vs. an incorrect number.
> 
> Or do you mean an Alert-Info URN would only be used for rendering
> decisions of 18x, and a Reason-header would be used for rendering
> decisions of other SIP responses?
> 
> -hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 May 2010 11:01:39 -0400

[Argh - I should have said "Other comments inline...", so re-sending the email corrected]

Hi Laura,

Other comments inline...

-hadriel

---

From: Xavier Marjou <[email-masked]>
Date: Mon, 17 May 2010 11:11:17 +0200

Hi,

I support the overall proposal of the two drafts.

Cheers,
Xavier

2010/5/13  <[email-masked]>:
> During the discussion concerning the Reason header field in Responses I was
> asked to split the document into an requirements part and an protocol part.
>
> Große Veränderungen fangen klein an – Ressourcen schonen und nicht jede
> E-Mail drucken.
>

---

From: Laura Liess <[email-masked]>
Date: Mon, 17 May 2010 15:18:20 +0200

Hi Hadriel,

I did some digging about how the Q.850 RELEASE causes are handled in
the DT PSTN and the Reason-Header in NGN.

Please find comments inline..

Also

2010/5/14 Hadriel Kaplan <[email-masked]>:
> Doesn't the PSTN-switch or PBX getting the response code use the Q.850 code to pick a specific tone sequence to play to a >handset in some cases?
>

[LL] It depends on the Cause-code.  Some cause- code result in a user
announcement, other result in a network action. E.g.  causes 34 "no
circuit available" and 42 "switching equipment congestion" result in
rerouting due to congestion, not in a user tone or announcement.
I like really very much Dale's text on this issue (3.rd paragraph in
his "Alert-Info thoughts"-mail).

Reason in responses are used for interworlking with PSTN. They are in
principle about extending the 3261 response code set to cover also
respose codes needed by PSTN. The difference between Alert Info URN
and reason codes is, from my point of view, similar to the difference
between Alert-Info URN and SIP response codes.
> I would think you'd want Alert-Info to apply to such failure responses too, no?  For example, there is a different tone presented today for a user-busy, vs. an all-circuits-busy, vs. an incorrect n…

[LL] PSTN users get a special tone for all-circuits-busy, in SIP we
don't need this. For the other two we have SIP response codes in
3261.

> Or do you mean an Alert-Info URN would only be used for rendering decisions of 18x, and a Reason-header would be used for rendering decisions of other SIP responses?

We have the reason in reaponses *only* for interworking with ISUP REL
message cause-codes. It never occures in connection setup messages or
responses (INVITE,  18x, OK ).  Network elements may check the reason
header and take call control decisions as rerouting the call, without
any information to the user.

Alert-Info URNs represent tones. The receiving end device only
resolves it to a tone and plays the tone. Nothing else.  The end
device does not look at  what the Alert-Info URN means, but only if it
has rules to resolve it to a concrete tone. If it has, it resolves the
URN, otherwise the URN is discarded. It can be call waiting or
Bethoven Fifth or the combination internal+short. The network will not
use the Alert-info URNs for the call control logic. The RFC 3261
allows Alert-Info in INVITE and 180. People agreed on the ML to exten
this to 18x.

Thanks
Laura

---

From: <[email-masked]>
Date: Tue, 18 May 2010 16:57:22 +0200

Hi John,
Thank you for your comments. 
It was asked to split the draft into requirements and at least procedures.

You are right that within the requirements draft is more that requirements. It is also the motivation, justification and examples. I can change the title if people are happy with it. Question is if such a draft is also needed as RFC or if it only seen as a temporary document during the discussion.

With regard to REQ-1 I propose the following re-wording:

It should be possible to support within native SIP environment PSTN-SIP-PSTN scenarios where the reason of a call release can be transferred though the SIP domain
without any loss of information and no change of reason.

I think this was discussed lengthy during the last meeting and email discussion.
Not each PSTN GW will support ISUP MIME encapsulation. At least the 3GPP IMS has no SIP. The IMS is not using SIP-T.

REQ-2 and REQ-3
Yes it looks similar.

REQ-3 was added because it was seen from user device perspective that the Device have the possibility to show the Q.850 cause but that such a End Device does not include Q.850 causes. Of course a MGC should have this possibility.

I would be happy to shrink REQ-2 and 3 to your proposed text.

REQ-2
It must be possible to provide an accurate indication to a UAC, so that the UAC can provide a suitable indication to the user. Whether this be an announcement, a textual message, an icon, a flashing lamp, a tone, a vibration, an odour or whatever, is a user interface matter.

REQ-4 was the consequence of REQ-3 where we do not allow the inclusion of a Q850 cause by a end device.

So the trick is not allow the SIP end device to include a Q850 cause and in some certain cases to allow an service provider controlled application server to include a Reason header with a Q.850 cause. But it should not be done generally by SIP applications. So normally a ISUP implementation will use ISUP causes but not SIP implementations.
But there are SIP Application servers out in the world that will have a ISUP application (or ISUP like application that reacts and behaves as within a ISUP network).

Question is now how to proceed further.

Are people happy to have the documents split or put again together with striking out the examples ect?
Or to have the documents as they are with some transfer of text to the draft-jesske-dispatch-reason-in-responses-02 draft?

Comments?

Thank you and Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]] 
Gesendet: Donnerstag, 13. Mai 2010 09:24
An: Jesske, Roland; [email-masked]
Betreff: RE: Reason In responses(draft-jesske-dispatch-reason-in-responses-02)

Roland,

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 18 May 2010 21:36:54 +0200

Roland, 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 18 May 2010 15:57
> To: Elwell, John; [email-masked]
> Subject: AW: Reason In 
> responses(draft-jesske-dispatch-reason-in-responses-02)
> 
> Hi John,
> You are right that within the requirements draft is more that 
> requirements. It is also the motivation, justification and 
> examples. I can change the title if people are happy with it. 
> Question is if such a draft is also needed as RFC or if it 
> only seen as a temporary document during the discussion.
[JRE] I was not proposing a title change, and I have no problem combining motivation with requirements, although I do feel the examples look too much like solution and are unnecessary. Although some people asked you to split the draft, in my opinion it was wasted effort, but it is done now.

> It should be possible to support within native SIP 
> environment PSTN-SIP-PSTN scenarios where the reason of a 
> call release can be transferred though the SIP domain
> Not each PSTN GW will support ISUP MIME encapsulation. At 
> least the 3GPP IMS has no SIP. The IMS is not using SIP-T.
[JRE] I don't think the new wording makes any difference. SIP-T is a means for tunnelling a Q.850 cause through a native SIP domain. The IETF already defines SIP-T as the solution, and if this solution is not sufficient, you need to cite reasons why not and identify a requirement that cannot be met using SIP-T. Just saying that IMS does not use SIP-T doesn't sound like a sufficient reason to me, because clearly IMS could be made to use SIP-T.

To be clear, I am not saying that the Reason header field should not be used in this situation, if the header field is defined for use in responses in general in order meet other requirements. I am simply saying that REQ-1 is not sufficient justification for allowing the Reason header field in responses, since REQ-1 can be satisfied using an existing mechanism.

> 
> REQ-2 and REQ-3
> Yes it looks similar.
> 
> REQ-3 was added because it was seen from user device 
> perspective that the Device have the possibility to show the 
> Q.850 cause but that such a End Device does not include Q.850 
> causes. Of course a MGC should have this possibility.
> 
> It must be possible to provide an accurate indication to a 
> UAC, so that the UAC can provide a suitable indication to the 
> user. Whether this be an announcement, a textual message, an 
> icon, a flashing lamp, a tone, a vibration, an odour or 
> whatever, is a user interface matter.
[JRE] I did not intend the second sentence to be part of the requirement - it was just for illustration of why the existing text, which focused on textual display, was inadequate.

> 
> REQ-4 was the consequence of REQ-3 where we do not allow the 
> inclusion of a Q850 cause by a end device.
> 
> So the trick is not allow the SIP end device to include a 
> Q850 cause and in some certain cases to allow an service 
> provider controlled application server to include a Reason 
> header with a Q.850 cause. But it should not be done 
> generally by SIP applications. So normally a ISUP 
> implementation will use ISUP causes but not SIP implementations.
> But there are SIP Application servers out in the world that 
> will have a ISUP application (or ISUP like application that 
> reacts and behaves as within a ISUP network).
[JRE] I found REQ-3 rather confusing. On re-reading it, the first sentence is a requirement concerning reception, and the second sentence seems (if I understand correctly) to be a statement about sending. Assuming my understanding is correct, making a statement, within a requirement, that something is out of scope seems to suggest it is not part of the requirement.

In addition, the way SIP is specified, there is no real distinction between different types of UA. In other words, SIP procedures for UAs apply to UAs in general, not to specific types of UA like ASs. So writing a requirement that tries to distinguish between different types of UA does not seem to make sense.

> Are people happy to have the documents split or put again 
> together with striking out the examples ect?
> Or to have the documents as they are with some transfer of 
> text to the draft-jesske-dispatch-reason-in-responses-02 draft?
[JRE] I don't have a strong opinion about document structure, although my personal preference would have been to leave it as one document, as it was originally. My main concern is trying to come up with a meaningful set of requirements, and in my opinion it reduces to a single requirement - being able to convey a Q.850 cause from PSTN (or similar) to a UAC so that the UAC can render meaningful information to the user.

John

> Betreff: RE: Reason In 
> responses(draft-jesske-dispatch-reason-in-responses-02)
> 
> Roland,
> 
> In my view, there is a simple requirement to convey Q.850 
> causes in SIP response messages, so that the UAC will receive 
> a more accurate indication of the reason for rejection when 
> rejection comes from PSTN. The cause mapping table helps to 
> illustrate this. This is not rocket science, and I am 
> disappointed that we have not found a quick way of 
> dispatching this and just getting the work done. In my 
> opinion the split into separate documents was unnecessary 
> (take as an example the recently-published RFC 5876, which 
> combines motivation and solution in one document), but it has 
> been done now. Unfortunately I don't think it has moved us 
> any further forward.
> 
> I don't think the requirements in section 3 are particularly 
> well expressed. REQ-1 can already be met by tunnelling in 
> accordance with SIP-T. I would not expect the IETF to provide 
> a new solution specifically for that requirement.
> 
> I think REQ-2 and REQ-3 boil down to the same thing - it must 
> be possible to provide an accurate indication to a UAC, so 
> that the UAC can provide a suitable indication to the user. 
> Whether this be an announcement, a textual message, an icon, 
> a flashing lamp, a tone, a vibration, an odour or whatever, 
> is a user interface matter.
> 
> I also find REQ-4 rather problematic. If we have a solution 
> for PSTN, we would also have a solution for some other form 
> of gateway into a domain that provides a "PSTN-like service". 
> Unfortunately, if you try to bring this out as a separate 
> requirement, it raises the question of what exactly is this 
> "PSTN-like service", and if it is somehow SIP-based, why it 
> needs to be "PSTN-like", and so on.
> 
> Basically I think there is only a single requirement here - 
> provision of a correct indication to a UAC when rejection 
> comes from the PSTN. I think that is a reasonable requirement 
> and we should just go ahead and do it, rather like we did 
> with RFC 5876 when we extended the range of messages that 
> PAI/PPI could be used in.
> 
> I find the statement in REQ-3 "A inclusion of [Q.850] causes 
> is out of scope." very strange. I thought the whole idea was 
> to convey Q.850 causes, so why say they are out of scope? I 
> assume this is some sort of typo.
> 
> I think one of the consequences of deciding to split 
> requirements and solution into separate drafts is that the 
> requirements draft has to stick to motivation and 
> requirements. I find too much in the draft (particularly the 
> examples) that smells of solution.
> 
> John
> 
>

---

From: Shida Schubert <[email-masked]>
Date: Wed, 19 May 2010 23:03:50 +0900

+1

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2010 15:45:32 -0400

> allows Alert-Info in INVITE and 180. People agreed on the ML to exten

I'd like to take issue with the above.
Due to precedent we all are biased towards *audio* alerts, but alerts 
need not be tones, or audio at all. Even for people who can hear, alerts 
that are, in part or wholly, non-audio are also important. E.g. 
everybody has reason to put their cellphone into vibrate mode at times.

	Thanks,
	Paul

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Wed, 19 May 2010 16:42:02 -0400

>> Thank you and Best Regrads

Yes, I think this work should go foward in accordance with these drafts.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 May 2010 08:01:28 +0200

Hi, 

>>Bethoven Fifth or the combination internal+short. The 
>>network will not use the Alert-info URNs for the call control logic. The RFC 3261 
>Due to precedent we all are biased towards *audio* alerts, 
>but alerts need not be tones, or audio at all. Even for 
>people who can hear, alerts that are, in part or wholly, 
>non-audio are also important. E.g. 

Of course. In that case you won't get an audio alert - no matter if you use Alert-Info or your "default" audio ring tone.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 May 2010 09:05:02 -0400

I changed the subject to be consistent with the content

> Of course. In that case you won't get an audio alert - no matter if you use Alert-Info or your "default" audio ring tone.

This is one of the values of Alert-Info URNs. The different alerting 
modes of your phone (normal, vibrate, ...) can simply select alternative 
sets of renderings of all the supported Alert-Info URNs.

	Thanks,
	Paul

---

From: "Patel, Milan" <[email-masked]>
Date: Thu, 20 May 2010 11:34:49 -0400

Hi,

I've read these drafts, and apart from a few editorials, I believe these
drafts accurately convey the use cases and solution for Reason in
responses. I agree with Dale, this work should go forwards based on
these drafts.

Regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of WORLEY, Dale R (Dale)
Sent: Wednesday, May 19, 2010 9:42 PM
To: Shida Schubert; Xavier Marjou
Cc: [email-masked]; [email-masked]
Subject: Re: [dispatch] Reason Inresponses
(draft-jesske-dispatch-reason-in-responses-02)

>> So far I didn't get any. Does that mean that people are happy now
with the

Dale

---

From: Laura Liess <[email-masked]>
Date: Thu, 20 May 2010 19:08:51 -0000

Paul,

Sorry, the wording was inaccurate in my e-mail. What I meant was renderings,
not just tones. In the draft we talk about renderings. We ever have some
text about the advantage of Alert-Info URN for hearing impaired. 

Thanks
Laura

> Von: Paul Kyzivat [mailto:[email-masked]]
> Gesendet: Donnerstag, 20. Mai 2010 15:05
> An: Christer Holmberg
> Cc: Laura Liess; [email-masked]; [email-masked]; Hadriel Kaplan
> Betreff: Alert-Info URNs - alternative renderings
> 
> > Of course. In that case you won't get an audio alert - no matter if you
> use Alert-Info or your "default" audio ring tone.
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 May 2010 13:35:16 +0200

+1

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Patel, Milan
Sent: 20. toukokuuta 2010 18:35
To: WORLEY, Dale R (Dale); Shida Schubert; Xavier Marjou
Cc: [email-masked]; [email-masked]
Subject: Re: [dispatch] Reason Inresponses (draft-jesske-dispatch-reason-in-responses-02)

Hi,

I've read these drafts, and apart from a few editorials, I believe these drafts accurately convey the use cases and solution for Reason in responses. I agree with Dale, this work should go forwards based on these drafts.

Regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of WORLEY, Dale R (Dale)
Sent: Wednesday, May 19, 2010 9:42 PM
To: Shida Schubert; Xavier Marjou
Cc: [email-masked]; [email-masked]
Subject: Re: [dispatch] Reason Inresponses

with the

Dale