Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss)

From: Laura Liess <[email-masked]>
Date: Thu, 1 Jul 2010 14:53:32 +0200

In the PSTN,  we use the UUI field to transmit information between the
Intelligent Network (IN) system and call center agents for the
directory enquires service. Everybody in Germany who wants to ask for
the phone number of another person dials DT's directory enquires
service and is connected to a call center agent who tells him the
number he wants to know. Additionaly, only if the caller is a DT
customer, the call center agent offers to connect him to this number,
so the caller does not need to dial. For everybode else, he does not.
So the call center agent needs to get the information whether or not
the caller is a DT customer. This is done by routing every directory
enquires call to the IN system first. The IN system checks the caller
number and inserts the information about whether or not the caller is
a DT-customer in the UUI field which is transmited via INAP, ISUP and
DSS1 to the call center agent's end device.The call center agent gets
a display about this. During the PSTN-migration to SIP, we will have
cases where the call center and the IN system are connected to
different networks, one to PSTN and the other to SIP.  Also, we may
have applications as above on pure SIP application servers.

> Can you shed some light on *how* this is used, given the lack of any
> standards on the content/formatting of this information?

The application is DT-specific and needs a DT specification to be
supported by the IN system and the call center, but the container to
transport the information must be supported by both ends and by the
network nodes.

> Or is this only used between a caller and a callee that have somehow
> obtained contextual information that they both support this feature *and* a
> particular encoding?

At least within the DT network, UUI is used between application
servers or application servers and "special" end devices as call
centers. As far as I know, UUI is currently not part of the DT normal
telephony package. Many years ago, it was, but people misused it.

We plan to use the "Johnston uui draft" for the scenario described
above and we see the need for the proposed WG.

Thanks a lot
Laura

Laura

2010/6/30 Paul Kyzivat <[email-masked]>:
> James,
>
> Can you shed some light on *how* this is used, given the lack of any
> standards on the content/formatting of this information?
>
> Do you use content=isdn-uui and some particular Q.931 protocol discriminator
> for which there are formatting standards?
>
> Or is this only used between a caller and a callee that have somehow
> obtained contextual information that they both support this feature *and* a
> particular encoding?
>
>        Thanks,
>        Paul
>
> James Rafferty wrote:
>>
>> Hi,
>> My company has had the experience of deploying the pre-standard version of
>> this PSTN to SIP UUI mechanism during the past 2 years.
>> As noted in the draft charter, UUI information is widely used on the PSTN
>> for applications such as offering input data into call centers and then
>> preserving that data as calls get transferred.
>> Since many contact centers are now built using SIP, but still have PSTN
>> subscribers (via SS7 ISUP or ISDN PRI), there is a need to be able to
>> interwork the user to user information from the PSTN side into SIP.  In our
>> experience, the "Johnston uui draft" has accomplished this and we have
>> several customers that find this interworking to be valuable.  We also noted
>> improvements from early drafts into the later ones in areas such as making
>> better use of the ITU-T protocol discriminator, thus enabling better
>> interoperability from the PSTN side into SIP.
>> The major deficiency of the current draft is its non-standard status.
>> Functionally, we and our customers find this mechanism to be very useful and
>> I'd very much like the IETF to charter the a UUI work group to standardize
>> such a mechanism.
>> James  -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Gonzalo Camarillo
>> Sent: Wednesday, June 30, 2010 2:51 AM
>> To: Paul Kyzivat
>> Cc: [email-masked]; DRAGE, Keith (Keith); [email-masked]
>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP
>> (cuss)
>>
>> Hi,
>>
>> please keep both the IETF and the DISPATCH mailing lists in the
>> recipients list in this discussion.
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>> On 29/06/2010 8:23 PM, Paul Kyzivat wrote:
>>>
>>> DRAGE, Keith (Keith) wrote:
>>>>
>>>> The UUI information is NOT ISUP. It is a transparent envelope to the
>>>> entire ISDN, so it is not part of an ISDN protocol and therefore not part of
>>>> an ISUP protocol. When carried by ISUP the envelope is bundled up in another
>>>> envelope with other information that ISUP carries transparently.
>>>>
>>>> So I believe, and have said repeatedly in the past, that references to
>>>> SIP-T are irrelevant in this case.
>>>>
>>>> The problem we do have though is that are legacy usages of this
>>>> information. In particular applications in PBXs carry it between themselves
>>>> in ISDN call establishment. The information itself is not standardised. If
>>>> you want to migrate a PBX from DSS1 to SIP, then you have to take this
>>>> information into account. The desire is not for a WG group to standardise
>>>> this existing usage (which in my view would be a complete non-starter), but
>>>> to allow the transfer of the existing information when migrated to a SIP
>>>> environment. The information transferred does not form part of SIP, and
>>>> should not be standardised as part of SIP.
>>>
>>> How many different mechanisms do we have to construct for the purpose of
>>> tunneling stuff over SIP?
>>>
>>> Its especially bad if the stuff is neither standardized nor negotiated.
>>> It then just provides more opportunity for non-interoperability.
>>>
>>> It had been my impression that this content was standardized by ITU.
>>> If nobody can bother to standardize it, then it hardly seems worth
>>> working on.
>>>
>>>        Thanks,
>>>        Paul
>>>
>>>> regards
>>>>
>>>> Keith
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of
>>>>> [email-masked]
>>>>> Sent: Tuesday, June 29, 2010 1:00 PM
>>>>> To: [email-masked]; [email-masked]
>>>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI
>>>>> for SIP (cuss)
>>>>>
>>>>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372
>>>>> does state that SIP-T does not come into play when there is
>>>>> no PSTN involved.
>>>>>
>>>>> At the end of clause 2 we can read the following: "4.  IP
>>>>> origination - IP termination: This is a case for pure SIP.
>>>>> SIP-T (either encapsulation or translation of ISUP) does not
>>>>> come into play as there is no PSTN interworking."
>>>>>
>>>>> Besides, SIP-T would require encapsulating a full ISUP
>>>>> message (e.g. IAM) while we are interested in just one
>>>>> parameter of the message in the context of CUSS. This would I
>>>>> believe be a more severe drawback if SIP-T were used for this purpose.
>>>>>
>>>>> Bruno
>>>>>
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : [email-masked]
>>>>>> [mailto:[email-masked]] De la part de Gonzalo Camarillo
>>>>>> Envoyé : mardi 29 juin 2010 13:03 À : DISPATCH Objet :
>>>>>
>>>>> [dispatch] Fwd:
>>>>>>
>>>>>> Re: WG Review: Call Control UUI for SIP (cuss)
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> FYI: note the discussion below on the IETF general list.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Gonzalo
>>>>>>
>>>>>> -------- Original Message --------
>>>>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss)
>>>>>> Date: Mon, 28 Jun 2010 20:24:23 +0200
>>>>>> From: Cullen Jennings <[email-masked]>
>>>>>> To: [email-masked] <[email-masked]>
>>>>>> CC: IETF Discussion Mailing List <[email-masked]>
>>>>>>
>>>>>>
>>>>>> As far as I can tell, the WG says they wants to transfer some
>>>>>> information to achieve cross vendor interoperability.
>>>>>> However, what I believe the charter is actually going to do
>>>>>
>>>>> is exactly
>>>>>>
>>>>>> the opposite of that. When you get your head around what
>>>>>
>>>>> this charter
>>>>>>
>>>>>> is proposing, it is going to form a more or less opaque
>>>>>
>>>>> container for
>>>>>>
>>>>>> transporting proprietary information in a SIP header. It's hard to
>>>>>> imagine how this will help interoperability.
>>>>>>
>>>>>> If we wanted to have interoperability, the charter would say what
>>>>>> information needs to be transferred and have the WG define a way to
>>>>>> get it between systems in an operable way.
>>>>>> What the charter for this WG actually says they are going to do is
>>>>>> make a special container for transfer proprietary information.
>>>>>> There's not even willing to say what that proprietary
>>>>>
>>>>> information is
>>>>>>
>>>>>> used for other than things ISDN UUI which is a  non
>>>>>
>>>>> interoperable and
>>>>>>
>>>>>> fairly proprietary field in ISDN.
>>>>>> Furthermore they have asserted that  existing containers
>>>>>
>>>>> such as SIP-T
>>>>>>
>>>>>> or SIP bodies can't be used for reasons that are hard to
>>>>>
>>>>> describe. (I
>>>>>>
>>>>>> reject the idea that because the call might not involved
>>>>>
>>>>> the PSTN, it
>>>>>>
>>>>>> can't use SIP-T).
>>>>>>
>>>>>> I think the folks that want to do this should get a much clear
>>>>>> explanation of how this results in interoperability and why exist
>>>>>> approach such as SIP-T will not work before this is chartered.
>>>>>>
>>>>>> I do think there is a need to standardize some important
>>>>>
>>>>> call control
>>>>>>
>>>>>> information used in call centers and related places.
>>>>>> However, the "we need a standard container to exchange secret
>>>>>> information WG" is a bad idea and violates the sprit of the
>>>>>
>>>>> SIP change
>>>>>>
>>>>>> process not to mention the mission of the IETF.
>>>>>>
>>>>>> In summary, I'm in favor of figuring out what the problems
>>>>>
>>>>> are people
>>>>>>
>>>>>> hope to solve with this WG and figuring out a way to write
>>>>>> interoperable standards to achieve that. However, I think
>>>>>
>>>>> this charter
>>>>>>
>>>>>> should be rejected by the IESG and sent back to the drawing
>>>>>
>>>>> board. The
>>>>>>
>>>>>> RAI area has things of higher priority items to work on than a SIP
>>>>>> header for transfer proprietary data.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote:
>>>>>>
>>>>>>> A new IETF working group has been proposed in the Real-time
>>>>>>> Applications and Infrastructure Area.  The IESG has not
>>>>>>
>>>>>> made any determination as yet.
>>>>>>>
>>>>>>> The following draft charter was submitted, and is provided for
>>>>>>> informational purposes only. Please send your comments to
>>>>>
>>>>> the IESG
>>>>>>>
>>>>>>> mailing list ([email-masked]) by Tuesday, June 29, 2010.
>>>>>>>
>>>>>>> Call Control UUI for SIP  (cuss)
>>>>>>> --------------------------------------------------
>>>>>>> Current Status: Proposed Working Group
>>>>>>>
>>>>>>> Last modified: 2010-06-21
>>>>>>>
>>>>>>> Chair(s):
>>>>>>>  TBD
>>>>>>>
>>>>>>> Real-time Applications and Infrastructure Area Director(s):
>>>>>>>  Gonzalo Camarillo <[email-masked]>
>>>>>
>>>>> Robert Sparks
>>>>>>>
>>>>>>> <[email-masked]>
>>>>>>>
>>>>>>> Real-time Applications and Infrastructure Area Advisor:
>>>>>>>  Gonzalo Camarillo <[email-masked]>
>>>>>>>
>>>>>>> Mailing Lists: TBD
>>>>>>>
>>>>>>> Description of Working Group:
>>>>>>>
>>>>>>> The Call Control UUI for SIP (CUSS) working group is chartered to
>>>>>>> define a Session Initiation Protocol (SIP) mechanism for
>>>>>>
>>>>>> transporting
>>>>>>>
>>>>>>> call-control related user-to-user information (UUI) between User
>>>>>>> Agents.
>>>>>>>
>>>>>>> The mechanism developed in this working group is
>>>>>
>>>>> applicable in the
>>>>>>>
>>>>>>> following situations:
>>>>>>>
>>>>>>> 1. The information is generated and consumed by an
>>>>>
>>>>> application using
>>>>>>>
>>>>>>>  SIP during session setup but the application is not necessarily
>>>>>>>  even SIP aware.
>>>>>>> 2. The behavior of SIP entities that support it is not
>>>>>
>>>>> significantly
>>>>>>>
>>>>>>>  changed (as discussed in Section 4 of RFC 5727).
>>>>>>> 3. Generally only the User Agent Client (UAC) and User
>>>>>
>>>>> Agent Server
>>>>>>>
>>>>>>>  (UAS) are interested in the information.
>>>>>>> 4. The information is expected to survive retargeting,
>>>>>
>>>>> redirection,
>>>>>>>
>>>>>>>  and transfers.
>>>>>>> 5. SIP elements may need to apply policy about passing
>>>>>
>>>>> and screening
>>>>>>>
>>>>>>>  the information.
>>>>>>> 6. Multi-vendor interoperability is important.
>>>>>>>
>>>>>>> This mechanism is not applicable in the following situations:
>>>>>>>
>>>>>>> 1. The behavior of SIP entities that support it is significantly
>>>>>>>  changed (as discussed in Section 4 of RFC 5727).
>>>>>>> 2. The information is generated and consumed at the SIP
>>>>>
>>>>> layer by SIP
>>>>>>>
>>>>>>>  elements.
>>>>>>> 3. SIP elements besides the UAC and UAS might be interested in
>>>>>>>  consuming (beyond applying policy) the information.
>>>>>>> 4. There are specific privacy issues involved with the information
>>>>>>>  being transported (e.g., geolocation or emergency-related
>>>>>>>  information).
>>>>>>>
>>>>>>> User data of the mechanism will be clearly marked with the
>>>>>>> application, encoding, semantics, and content type,
>>>>>>
>>>>>> allowing policy to
>>>>>>>
>>>>>>> be applied by UAs.  The working group will define the
>>>>>>
>>>>>> information that
>>>>>>>
>>>>>>> each application must specify to utilize the mechanism.
>>>>>>
>>>>>> This type of
>>>>>>>
>>>>>>> application-specific information will be specified in
>>>>>>
>>>>>> standards-track
>>>>>>>
>>>>>>> documents.
>>>>>>>
>>>>>>> One important application of this mechanism is interworking
>>>>>>
>>>>>> with the
>>>>>>>
>>>>>>> ISDN User to User Information Service.  This application
>>>>>
>>>>> defined by
>>>>>>>
>>>>>>> ITU-T Q.931 is extensively deployed in the PSTN today
>>>>>>
>>>>>> supporting such
>>>>>>>
>>>>>>> applications as contact centers, call centers, and automatic call
>>>>>>> distributors (ACDs).  A major barrier to the movement of these
>>>>>>> applications to SIP is the lack of a standard mechanism to
>>>>>>
>>>>>> transport
>>>>>>>
>>>>>>> this information in SIP.  For interworking with ISDN, minimal
>>>>>>> information about the content of the UUI is available to
>>>>>>
>>>>>> the PSTN-SIP
>>>>>>>
>>>>>>> gateways.  In this case only, the content will just
>>>>>>
>>>>>> indicate ISDN UUI
>>>>>>>
>>>>>>> Service 1 interworking rather than the actual content.
>>>>>>>
>>>>>>> Call control UUI is user information conveyed between user agents
>>>>>>> during call control operations.  As a result, the
>>>>>>
>>>>>> information must be
>>>>>>>
>>>>>>> conveyed with the INVITE transaction, and must survive proxy
>>>>>>> retargeting, redirection, and transfers.  The mechanism
>>>>>>
>>>>>> must utilize a
>>>>>>>
>>>>>>> minimum of SIP extensions since it will need to be
>>>>>>
>>>>>> supported by many
>>>>>>>
>>>>>>> simple SIP user agents such as PSTN gateways.  The mechanism must
>>>>>>> interwork with the existing ISDN service but should also be
>>>>>>
>>>>>> extensible
>>>>>>>
>>>>>>> for use by other applications and non-ISDN protocols.
>>>>>>>
>>>>>>> Even though interworking with the PSTN is an important
>>>>>
>>>>> requirement,
>>>>>>>
>>>>>>> call control UUI can be exchanged between native SIP
>>>>>>
>>>>>> clients that do
>>>>>>>
>>>>>>> not have any ISUP support. Therefore, existing SIP-T
>>>>>>> encapsulation-based approaches defined in RFC3372 do not meet the
>>>>>>> requirements to transport this type of information.
>>>>>>>
>>>>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be
>>>>>>> considered by the working group since the UUI contents carry
>>>>>>> information that must be conveyed during session setup at
>>>>>
>>>>> the user
>>>>>>>
>>>>>>> agent - the information must be conveyed with the INVITE
>>>>>>
>>>>>> transaction.
>>>>>>>
>>>>>>> The information must be passed with the session setup request
>>>>>>> (INVITE), responses to that INVITE, or session
>>>>>
>>>>> termination requests.
>>>>>>>
>>>>>>> As a result, it is not possible to use INFO in these cases.
>>>>>>>
>>>>>>> The group will produce:
>>>>>>>
>>>>>>> - A problem statement and requirements document for
>>>>>>
>>>>>> implementing a SIP
>>>>>>>
>>>>>>> call control UUI mechanism
>>>>>>>
>>>>>>> - A specification of the SIP extension to best meet those
>>>>>>
>>>>>> requirements.
>>>>>>>
>>>>>>> Goals and Milestones
>>>>>>> ====================
>>>>>>>
>>>>>>> Sep 10 - Problem statement and requirements document to IESG
>>>>>>> (Informational)
>>>>>>> Mar 11 - SIP call control UUI specification to IESG (PS)
>>>>>>> _______________________________________________
>>>>>>> IETF-Announce mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>>>>
>>>>>> Cullen Jennings
>>>>>> For corporate legal information go to:
>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dispatch mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>>
>>>>> _______________________________________________
>>>>> dispatch mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Thu, 1 Jul 2010 09:56:27 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Laura Liess [[email-masked]]
Sent: Thursday, July 01, 2010 8:53 AM

Can you tell us about the misuse?  It might be relevant to the expected usage of the cuss feature.

Dale

---

From: Laura Liess <[email-masked]>
Date: Thu, 1 Jul 2010 16:28:26 +0200

> Can you tell us about the misuse?  It might be relevant to the expected usage of the cuss feature.

I was relevant for that time, when communication was expensive and
telephony was billed per minute...

In Germany's PSTN, carriers are not allowed to bill for signalling,
only for the voice channel usage. Some smart guys built devices which
sent many SETUPs messages with UUI and canceled the call setup
immediately. So they transmitted their information without paying
anything and causing high load on the signalling network.

Thanks
Laura

---

From: James Rafferty <[email-masked]>
Date: Wed, 30 Jun 2010 13:56:10 -0400

Hi, 

My company has had the experience of deploying the pre-standard version of this PSTN to SIP UUI mechanism during the past 2 years.  

As noted in the draft charter, UUI information is widely used on the PSTN for applications such as offering input data into call centers and then preserving that data as calls get transferred.  

Since many contact centers are now built using SIP, but still have PSTN subscribers (via SS7 ISUP or ISDN PRI), there is a need to be able to interwork the user to user information from the PSTN side into SIP.  In our experience, the "Johnston uui draft" has accomplished this and we have several customers that find this interworking to be valuable.  We also noted improvements from early drafts into the later ones in areas such as making better use of the ITU-T protocol discriminator, thus enabling better interoperability from the PSTN side into SIP.   

The major deficiency of the current draft is its non-standard status. Functionally, we and our customers find this mechanism to be very useful and I'd very much like the IETF to charter the a UUI work group to standardize such a mechanism.  

James  
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: Wednesday, June 30, 2010 2:51 AM
To: Paul Kyzivat
Cc: [email-masked]; DRAGE, Keith (Keith); [email-masked]
Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss)

Hi,

Cheers,

Gonzalo

On 29/06/2010 8:23 PM, Paul Kyzivat wrote:
>> The UUI information is NOT ISUP. It is a transparent envelope to the entire ISDN, so it is not part of an ISDN protocol and therefore not part of an ISUP protocol. When carried by ISUP the envelope is bundled up in another envelope with other information that ISUP carries transparently.
>>
>> So I believe, and have said repeatedly in the past, that references to SIP-T are irrelevant in this case.
>>
>> The problem we do have though is that are legacy usages of this information. In particular applications in PBXs carry it between themselves in ISDN call establishment. The information itself is not standardised. If you want to migrate a PBX from DSS1 to SIP, then you have to take this information into account. The desire is not for a WG group to standardise this existing usage (which in my view would be a complete non-starter), but to allow the transfer of the existing information when migrated to a SIP environment. The information transferred does not form part of SIP, and should not be standardised as part of SIP.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Jun 2010 14:19:58 -0400

James,

Do you use content=isdn-uui and some particular Q.931 protocol 
discriminator for which there are formatting standards?

Or is this only used between a caller and a callee that have somehow 
obtained contextual information that they both support this feature 
*and* a particular encoding?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Jun 2010 19:20:33 -0400

Mohamed Elithy wrote:
> Hi!
> We are currently adding all 3 parameters (encoding, content, and purpose) in case of an ISDN --> SIP initiated call with their specified default values defined in section 5 of the draft.
> 
> As far as the formatting, as the draft specifies the first byte of the header value is the protocol discriminator. we found that the best way to satisfy multiple customers dealing with different types of encoding is to pass the protocol discriminator along with the raw byte stream from the UUI IE on the ISDN side to the UUI header on the SIP side. This way the SIP AS or any other SIP entity receiving that header can decide how to decode the UUI info based on the value of the protocol discriminator.

I got all that. My question was about what specific value(s?) of the 
protocol discriminator are you using, and how do they correspond to the 
rest of the value.

The same question would apply if sip were not involved at all - if the 
call were an ISDN call.

Is there a broad based convention that most call center sw will use a 
particular encoding?

Or is it well known that certain commercial products use certain encodings?

Or is this just a private side arrangement configured between the caller 
and the callee in a specific deployment?

	Thanks,
	Paul

> Hope this helps.
> 
> Regards,
> -Mohamed
> 
> Mohamed Elithy | Engineering Manager/Architect | Dialogic Inc. | [email-masked] | 508-862-3722 W | 508-364-5526 M
> 
> This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail.
> 
> 
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, June 30, 2010 2:20 PM
> To: James Rafferty
> Cc: Gonzalo Camarillo; [email-masked]; DRAGE, Keith (Keith); [email-masked]; Mohamed Elithy

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Jul 2010 13:55:10 -0600

This example is excellent - thank you for providing it. I think it is pretty representative of other examples I have seen and I am in favor of having solutions to use cases such as this - I'm just not seeing why this charter is the appropriate way to do it.

Given we are talking about transferring some information between UA in a single providers network, and this information would likely be stripped by an SBC at the edge of the network, and that different operators may use the same code points for different things, this all seems like something that might just be better carried in one of the existing SIP extensibility mechanisms such as media-type out of the vendor tree.

Cullen

PS - I doing my best to avoid the debate on if the CSCF are proxies or B2BUA, I view things that need to understand and even change SIP bodies as B2BUA but regardless, I think we can both agree that CSCF can and do look at bodies such as SDP and would work with what I proposed above. 

On Jul 1, 2010, at 6:53 AM, Laura Liess wrote:

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

Cullen Jennings

---

From: Laura Liess <[email-masked]>
Date: Fri, 9 Jul 2010 16:39:02 +0200

Cullen,

> Given we are talking about transferring some information between UA in a single providers network,

Laura:
As I wrote in a previous e-mail, we also have enterprise customers
which already bought this feature from us for the PSTN. We don't know
how they use it, but we need to give them the same feature for SIP.

> PS - I doing my best to avoid the debate on if the CSCF are proxies or B2BUA, I view things that need to understand and even change SIP bodies as B2BUA but regardless, I think we can both agree tha…

Laura:
In IMS we have different kinds of CSCFs.  In principle, all of them
can be either proxy or some kind of B2BUA.  In the DT IMS, the CSCF
doing SIP-routing and filtering based on user profile, is a proxy.
(Other CSCFs, e.g. those at the network border, are B2BUAs, but they
can not do the filtering.) Is it so easy to instruct a proxy to
inspect the body and eventually throw away a part of it? And should
one do that?

Thanks
Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Jul 2010 10:59:31 -0400

Laura Liess wrote:

> Is it so easy to instruct a proxy to

While a proxy may inspect a body (if its not encrypted),
by definition a proxy may not modify or remove a body.

	Thanks,
	Paul