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

[<[e-mail]>]

Hi John,
After reading this thread again, I would like to propose two requirements as follows:

REQ-1:
It should be possible to support 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.</t

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.



As an additional Option there could be a third one as follows:

REQ-3:

UA may have the ability to display ISUP specific release causes or show a equivalent text. 


Please indicate if you see this RE-3 within the scope or if it is already covered by REQ-2.

Opinions. 

If people are happy I will provide an updated draft.

Best Regards

Roland



Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
[phone] (Tel.)
[phone]  (Fax)
[phone]  (Mobil)
E-Mail: [e-mail]
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.


-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[e-mail]] 
Gesendet: Dienstag, 15. Juni 2010 16:28
An: Jesske, Roland; [e-mail]
Betreff: RE: Reason In responses(draft-jesske-dispatch-reason-in-responses-02)

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: 07 June 2010 06:59
> To: Elwell, John; [e-mail]
> Subject: AW: Reason In 
> responses(draft-jesske-dispatch-reason-in-responses-02)
> 
> Hi John,
> Thank you for your comments:
> Here are my view.
> 
> REQ-1:
> I think that REQ-1 is still a justification, because not each 
> Operator will use SIP-T for tunnelling purposes.
> If you pass an untrusted domain SIP-T should not part, 
> because it could include restricted numbers or other 
> information that should not be presented to untrusted networks.
> 
> Also only for passing the Q.850 Cause code to encapsulate the 
> whole ISUP is a little over dimensioned.
> The SIP-T MIME can be lost due to the interdomain trust 
> relation ships which the Reason header cannot.
> 
> For in an multi carrier/service provider environment like 
> Germany is, it will not be secure that each operator will 
> support SIP-T. 
[JRE] This helps to explain why SIP-T is not sufficient. IF SIP-T requires you to include additional information that you may not want to include when going outside a domain, that would be a reason for requiring a different solution. This was not made clear before.

John

> 
> 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.
> 
> So that is the proposal for REQ-2.
> 
> REQ-3 
>    A UA may have the ability to display ISUP specific release 
> causes or
>    show a equivalent text.
> 
> So that would be sufficient enough for REQ-3. If people would 
> like to see such text.
> 
> REQ-3/4
> Your comment with regard to the type of UA is correct. I 
> tried to satisfy people. The fact is that is not intended to 
> include the Q.850 cause by an SIP end device. So the 
> conclusion is changing REQ-3 and deleting REQ-4.
> 
> So now I would like to ask the people which requirements they 
> would like to see in the draft.
> As I understand John he sees only one (REQ-2)
> 
> I propose REQ-1, -2 and -3.
> 
> Opinions?
> 
> Thank you and Best Regards
> 
> Roland
> 
> 
> Deutsche Telekom Netzproduktion GmbH
> Zentrum Technik Einführung
> Roland Jesske
> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
> [phone] (Tel.)
> [phone]  (Fax)
> [phone]  (Mobil)
> E-Mail: mailto:[e-mail]
> http://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.
> 
> -----Ursprüngliche Nachricht-----
> Von: Elwell, John [mailto:[e-mail]] 
> Gesendet: Dienstag, 18. Mai 2010 21:37
> An: Jesske, Roland; [e-mail]
> Betreff: RE: Reason In 
> responses(draft-jesske-dispatch-reason-in-responses-02)
> 
> Roland, 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 
> > Sent: 18 May 2010 15:57
> > To: Elwell, John; [e-mail]
> > Subject: AW: Reason In 
> > responses(draft-jesske-dispatch-reason-in-responses-02)
> > 
> > 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.
> [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.
> 
> > 
> > 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.
> [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.
> > 
> > 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.
> [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.
> 
> > 
> > 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?
> [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
> 
> 
> > 
> > Comments?
> > 
> > Thank you and Best Regards
> > 
> > Roland
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: Elwell, John [mailto:[e-mail]] 
> > Gesendet: Donnerstag, 13. Mai 2010 09:24
> > An: Jesske, Roland; [e-mail]
> > 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
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> > > Sent: 13 May 2010 03:05
> > > To: [e-mail]
> > > Subject: Re: [dispatch] Reason In responses 
> > > (draft-jesske-dispatch-reason-in-responses-02)
> > > 
> > > 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:     [e-mail] 
> > > 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-respo
> > > nses-02 
> > > <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-r
> > > esponses-00 
> > > <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 
> > > [phone] (Tel.) 
> > > [phone]  (Fax) 
> > > [phone]  (Mobil) 
> > > E-Mail: [e-mail] <mailto:[e-mail]>  
> > > www.telekom.com <http: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. 
> > > 
> > > 
> > > 
> > 
>