Subject: [Sipping] Comment on draft-johnston-sipping-cc-uui-04

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 28 Jul 2008 00:21:02 +0200

I have the following comment on:

http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc-uui-04.txt

This document claims to mimic the ISDN service.

The ISDN service definition states (both ITU-T and ETSI are the same):

"The UUS supplementary service enables a user to send/receive a limited
amount of information to/from
another user over the signalling channel in association with a call to
the other user. This information shall
be passed transparently (i.e. without modification of contents) through
the network. The network shall not
interpret or act upon this information."

Therefore, usages involving a proxy are incorrect if the requirement is
to the defined the ISDN service.

The user is the calling endpoint, to the addressed endpoint (even after
redirection).

There were ETSI usages involving UUS and PBX, but in this case the PBX
itself was the addressed endpoint.

Therefore sections 3.2, and 3.3 define as a use case something which is
not the original ISDN service, but rather something new. As the
justification of the entire document is to solve the signalling problems
associated with interworking, then surely we should not be changing the
service definitions. 

If we do change the service definition, then we end up with a mechanism
that is general to all SIP, which basically says

REQ: provide a container containing non-standardised information between
any two SIP entities. 

This surely breaks the whole ideas of RFC 3427.

Please note that I have no problem with the idea of a header supporting
strict emulation of the ISDN service as defined by ITU-T and ETSI.

I would note that I would prefer to see something much more tangible
passed from the SIPPING group to SIP with some real documented
requirements. It is inappropriate to pass the solution to SIP as the
only documentation, and this is essentially what this draft does. Can we
formulate some statement(s) that enshrine the requirements SIP needs to
provide a solution to meet. "A mechanism is required to..." even if it
just completes "to emulate the UUS service 1 implicit defined in ITU-T
Recommendation Q.957.1 between two UAs".

Regards

Keith
_______________________________________________
Sipping mailing list  https://www.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: <[email-masked]>
Date: Mon, 28 Jul 2008 11:34:59 +0200

Keith, 

I think also the ISDN-world didn't always complies to this requirement. As far as I know, there are INAP-parametes which are translated in ISUP UUS. (I still have to check with my IN- colleagues about it and I will come back to you.) IN will be replaced with AS and we need a parameter in SIP which we can translate to UUS. We don't know if the AS  will be a B2BUA. If UUS is a MIME body, this means a restriction for the AS. 

Regards
Laura

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von DRAGE, Keith (Keith)
Gesendet: Montag, 28. Juli 2008 00:21
An: [email-masked]
Cc: [email-masked]
Betreff: [Sipping] Comment on draft-johnston-sipping-cc-uui-04

I have the following comment on:
 also may get scenarios in
http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc-uui-04.txt

r

Regards

Keith

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 28 Jul 2008 11:42:19 +0200

As I said, this document is short on requirements.

The only requirement you currently have is an implied one to match the ISDN service. 

However you then identify use cases that do not.

You need to be consistent.

I would point out that the current 3GPP work which came from your organisation does not allow proxy handling - the proxy functionality translates down to "if I support the extension, then pass on transparently".

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, July 28, 2008 10:35 AM
> To: DRAGE, Keith (Keith); [email-masked]
> Cc: [email-masked]
> Subject: AW: [Sipping] Comment on draft-johnston-sipping-cc-uui-04
> 
> Keith, 
> 
> I think also the ISDN-world didn't always complies to this 
> requirement. As far as I know, there are INAP-parametes which 
> are translated in ISUP UUS. (I still have to check with my 
> IN- colleagues about it and I will come back to you.) IN will 
> be replaced with AS and we need a parameter in SIP which we 
> can translate to UUS. We don't know if the AS  will be a 
> B2BUA. If UUS is a MIME body, this means a restriction for the AS. 
> 
> Regards
> Laura
> 
>   
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von DRAGE, Keith (Keith)
> "The UUS supplementary service enables a user to send/receive 
> a limited amount of information to/from another user over the 
> signalling channel in association with a call to the other 
> user. This information shall be passed transparently (i.e. 
> without modification of contents) through the network. The 
> network shall not interpret or act upon this information."
> r
> Therefore, usages involving a proxy are incorrect if the 
> requirement is to the defined the ISDN service.
> 
> The user is the calling endpoint, to the addressed endpoint 
> (even after redirection).
> 
> There were ETSI usages involving UUS and PBX, but in this 
> case the PBX itself was the addressed endpoint.
> 
> Therefore sections 3.2, and 3.3 define as a use case 
> something which is not the original ISDN service, but rather 
> something new. As the justification of the entire document is 
> to solve the signalling problems associated with 
> interworking, then surely we should not be changing the 
> service definitions. 
> 
> If we do change the service definition, then we end up with a 
> mechanism that is general to all SIP, which basically says
> 
> REQ: provide a container containing non-standardised 
> information between any two SIP entities. 
> 
> Please note that I have no problem with the idea of a header 
> supporting strict emulation of the ISDN service as defined by 
> ITU-T and ETSI.
> 
> I would note that I would prefer to see something much more 
> tangible passed from the SIPPING group to SIP with some real 
> documented requirements. It is inappropriate to pass the 
> solution to SIP as the only documentation, and this is 
> essentially what this draft does. Can we formulate some 
> statement(s) that enshrine the requirements SIP needs to 
> provide a solution to meet. "A mechanism is required to..." 
> even if it just completes "to emulate the UUS service 1 
> implicit defined in ITU-T Recommendation Q.957.1 between two UAs".
> 
> 
> Regards
> 
> Keith
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>