Subject: [MEDIACTRL] SIP-VXML - 5.2 REFER Mechanism for outbound calls

From: RJ Auburn <[email-masked]>
Date: Mon, 3 Dec 2007 18:31:03 -0500

Folks,

I really hate to bring this up so late in the game but one of the  
sections of the SIP-VXML draft that has really given me concern is the  
REFER mechanism for outbound calls (section 5.2). Overall I think this  
section needs somemore detail before I would be comfortable with it  
becoming an RFC. My concerns come down to two main points:

* Security - As it stands right now all we have said is that platforms  
should have some sort of local security policy  but there is very  
little in the way of details on how it is managed or implemented.  
Given that in this case sending a REFER outside of an existing dialog  
causes a number of billing related issues that can come up (for  
example if evil.org decided to send a REFER request to a VoiceXML  
platform to cause it to dial toll services causing charges to be sent  
to the owner of the media server).

* AS vs MS responsibility for placing calls - Architecturally it  
really feels to me we are mixing things up when we have the media  
server placing outbound calls without an AS controlling the session.  
the 3rd party call control option as specified in 5.1 personally seems  
like a *much* better fit and in general seems to align much closer  
with how I have seen VXML platforms deployed in the field. To be fair  
<transfer> is guilty of this as well and I am not sure we should kill  
it off but I would really rather avoid muddling the waters any more  
then we have to with adding pure outbound calling via REFER.

My preference would be to strike 5.2 from the document and leave 5.1  
(3rd party call control) as the recommended approach to establishing  
outbound VoiceXML sessions. The result is something that lines up very  
well with how I have seen system being deployed and is able to avoid  
stepping into a number of security issues that come out of REFER based  
outbound calling.

Thoughts?

	RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Eric Burger <[email-masked]>
Date: Thu, 06 Dec 2007 17:02:11 -0800

<contributor hat on>
My preference would be to KILL <transfer> once and for all.  It has no right
to exist.

However, it is still Optional in VoiceXML 2.1, so we have to live with it.
I would almost say, "Live by the sword, die by the sword."  If you have a
media server that allows <transfer>, by definition the application does not
care about billing, and so the blind REFER is OK.

Conversely, if you own a media server and do care about billing, you will
not honor a <transfer> request in your interpreter.

> stepping into a number of security issues that come out of REFER based

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: "Dave Burke" <[email-masked]>
Date: Fri, 7 Dec 2007 18:42:26 +0000

So, I'm inclined to agree with RJ that REFER outside of a dialog to initiate
outbound calls is dangerous and that simply omitting section 5.2 is the fix.

To be clear, the use of REFER for call transfer, on the other hand, does not
suffer the problems RJ mentions (since the application server is the
receiver of the REFER) and for this reason and others (like VoiceXML has
transfer and people use it in a variety of architectures), I would like to
keep the transfer section as is.

Dave

On the subject of call transfer, I would prefer to leave this section in.

On Dec 7, 2007 1:02 AM, Eric Burger <[email-masked]> wrote:

> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and
> have received this message in error, please immediately return this by email
> and then delete it.
>
>

---

From: RJ Auburn <[email-masked]>
Date: Mon, 10 Dec 2007 13:16:07 -0500

As David says REFER outbound and <transfer> are two different things.  
I would love to kill of <transfer> as well but recognize that is not  
an option at this point.

It sounds like nobody  is really in love with the REFER based outbound  
interface as specified in 5.2. Assuming noone comes up with a reason  
not to it sounds like killing it off may be a quick and easy thing to  
do here.

	RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

On Dec 7, 2007, at 13:42 :26, Dave Burke wrote:

> So, I'm inclined to agree with RJ that REFER outside of a dialog to  
> initiate outbound calls is dangerous and that simply omitting  
> section 5.2 is the fix.
>
> To be clear, the use of REFER for call transfer, on the other hand,  
> does not suffer the problems RJ mentions (since the application  
> server is the receiver of the REFER) and for this reason and others  
> (like VoiceXML has transfer and people use it in a variety of  
> architectures), I would like to keep the transfer section as is.
>
> Dave
>
> Notice:  This email message, together with any attachments, may  
> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and   
> affiliated entities,  that may be confidential,  proprietary,   
> copyrighted  and/or legally privileged, and is intended solely for  
> the use of the individual or entity named in this message. If you  
> are not the intended recipient, and have received this message in  
> error, please immediately return this by email and then delete it.
>
>

---

From: Dan York <[email-masked]>
Date: Thu, 20 Dec 2007 13:46:11 -0500

If section 5.2 is simply removed as per the ongoing discussion, you  
can ignore this comment.

If the section is retained in some modified form, I would just point  
out that the call flow diagram under 5.2 is the reverse of all the  
other call flows in the document.  In all other similar call flows  
(2.6.x, 3.2, , "User Agent" is on the left and "HTTP Application  
Server" is on the right.  The call flow in 5.2 is the opposite - HTTP  
App Svr on left and UA on right.  I would suggest it be changed to be  
consistent with all other similar call flows.

Again, if the entire section 5.2 is simply removed, the issue of the  
reversed call flow goes away.

Regards,
Dan

On Dec 10, 2007, at 1:16 PM, RJ Auburn wrote:

> As David says REFER outbound and <transfer> are two different  
> things. I would love to kill of <transfer> as well but recognize  
> that is not an option at this point.
>
> It sounds like nobody  is really in love with the REFER based  
> outbound interface as specified in 5.2. Assuming noone comes up  
> with a reason not to it sounds like killing it off may be a quick  
> and easy thing to do here.
>
> 	RJ
>
> ---
> RJ Auburn
> CTO, Voxeo Corporation
> tel:+1-407-418-1800
>
>
>
>> So, I'm inclined to agree with RJ that REFER outside of a dialog  
>> to initiate outbound calls is dangerous and that simply omitting  
>> section 5.2 is the fix.
>>
>> To be clear, the use of REFER for call transfer, on the other  
>> hand, does not suffer the problems RJ mentions (since the  
>> application server is the receiver of the REFER) and for this  
>> reason and others (like VoiceXML has transfer and people use it in  
>> a variety of architectures), I would like to keep the transfer  
>> section as is.
>>
>> Dave
>>
>> contain information  of  BEA Systems,  Inc.,  its subsidiaries   
>> and  affiliated entities,  that may be confidential,   
>> proprietary,  copyrighted  and/or legally privileged, and is  
>> intended solely for the use of the individual or entity named in  
>> this message. If you are not the intended recipient, and have  
>> received this message in error, please immediately return this by  
>> email and then delete it.
>>
>>

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 20 Dec 2007 15:14:57 -0800

<chair-hat off>
I would love to see 5.2 just go away.

<chair-hat on>
Anyone want to see it stay? 

________________________________

From: Dan York [mailto:[email-masked]] 
Sent: Thursday, December 20, 2007 1:46 PM
To: RJ Auburn
Cc: David Burke; [email-masked]
Subject: Re: [MEDIACTRL] SIP-VXML - 5.2 REFER Mechanism for outbound
calls

If section 5.2 is simply removed as per the ongoing discussion, you can
ignore this comment.   

If the section is retained in some modified form, I would just point out
that the call flow diagram under 5.2 is the reverse of all the other
call flows in the document.  In all other similar call flows (2.6.x,
3.2, , "User Agent" is on the left and "HTTP Application Server" is on
the right.  The call flow in 5.2 is the opposite - HTTP App Svr on left
and UA on right.  I would suggest it be changed to be consistent with
all other similar call flows. 

Regards,
Dan

	As David says REFER outbound and <transfer> are two different
things. I would love to kill of <transfer> as well but recognize that is
not an option at this point.

	It sounds like nobody  is really in love with the REFER based
outbound interface as specified in 5.2. Assuming noone comes up with a
reason not to it sounds like killing it off may be a quick and easy
thing to do here. 

	RJ

		---
	RJ Auburn
	CTO, Voxeo Corporation
	tel:+1-407-418-1800

		So, I'm inclined to agree with RJ that REFER outside of
a dialog to initiate outbound calls is dangerous and that simply
omitting section 5.2 is the fix. 
		
		To be clear, the use of REFER for call transfer, on the
other hand, does not suffer the problems RJ mentions (since the
application server is the receiver of the REFER) and for this reason and
others (like VoiceXML has transfer and people use it in a variety of
architectures), I would like to keep the transfer section as is. 
		
		Dave
		
		On the subject of call transfer, I would prefer to leave
this section in. 

		On Dec 7, 2007 1:02 AM, Eric Burger <[email-masked]>
wrote: 

			<contributor hat on>
			My preference would be to KILL <transfer> once
and for all.  It has no right 
			to exist.
			
			However, it is still Optional in VoiceXML 2.1,
so we have to live with it.
			I would almost say, "Live by the sword, die by
the sword."  If you have a
			media server that allows <transfer>, by
definition the application does not 
			care about billing, and so the blind REFER is
OK.
			
			Conversely, if you own a media server and do
care about billing, you will
			not honor a <transfer> request in your
interpreter.

			> stepping into a number of security issues that
come out of REFER based

			Notice:  This email message, together with any
attachments, may contain information  of  BEA Systems,  Inc.,  its
subsidiaries  and  affiliated entities,  that may be confidential,
proprietary,  copyrighted  and/or legally privileged, and is intended
solely for the use of the individual or entity named in this message. If
you are not the intended recipient, and have received this message in
error, please immediately return this by email and then delete it.

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 20 Dec 2007 20:41:14 -0800

Hi Everyone,

Thanks to Eric for sending this explicitly to my E-mail address; for
some reason I updated my sip and sipping subscriptions but not my
mediactrl one, so I had missed this entire dialog.  That would have been
a shame, since I believe I was the one responsible for this mechanism
appearing here in the first place!

First, let me say that there seems to be a fair amount of consensus here
that this should go away.  Despite proposing this, I'm not married to it
being there, so if this is the consensus of the group then I can
certainly live with it.  But before we axe it, I'd like to discuss some
of the points as a reminder of why it is there in the first place.

1.  Virtually everyone on mediactrl and most of us as participants come
from an environment in which there's always an application server
present.  However, it was intended that draft-ietf-mediactrl-vxml be
applicable even in the simplest environments possible, as described in
section 1.1.2 - where there's just a media gateway, a VoiceXML Media
Server, and no other elements.

This scenario is exactly why <transfer> was relevant enough to still be
in VoiceXML 2.1.  And while I've personally always advocated an
application server based approach, whether using CCXML or some other
mechanism for writing application server logic, it is definitely the
case that there are a very, very large number of deployments out there
that look exactly like section 1.1.2.  I do believe there's substantial
value in defining draft-ietf-mediactrl-vxml broadly enough that it
applies whether you're in this trivial situation, or you've got an
intelligent application server making full use of the specified
interface.

In these simplistic cases there's often only two "call control"
operations of interest - hang up, or transfer to an agent.  In such
situations, suggesting to the end user that they (a) deploy an
application server, (b) split the (trivial) "call control" vs. dialog
portions of their applications, and (c) learn a new language like CCXML
or JSR-116/289 to handle the application server pieces results in
exactly one answer: "Why?"  For these people, <transfer> is entirely
sufficient.

That's not the main issue in this thread, but as someone who did at one
point wish that <transfer> was never defined, I do see that being able
to handle the simple cases simply does have some value.  This point of
view is relevant in dealing with the real issue here.

This statement isn't self-serving at all, by the way; the next version
of our own products will *always* use a SIP AS in front of the MS, but
I've definitely seen enough of the simple scenarios to understand the
other view.

2.  The real debate here is about 5.2 and REFER outside a dialog to
trigger an outbound call.  

Above, I argued that there are a lot of deployments using the simple MG
<-> MS scenario, who don't have (or want) an application server in the
picture.  One thing, beyond hangup and transfer, that many of these
applications *do* want is the ability to make an outbound call.  As a
consequence, this is something that virtually every VoiceXML platform
provides some mechanism for accomplishing (without requiring the use of
an application server).

An obvious and immediate argument is that sending a REFER to perform an
outbound call requires a UA anyways, and if you're going to go that far,
why not just put an AS there?  There's some validity to that, but there
are substantial differences.  It's a lot easier to send a REFER to an
MS, where the only two things you need to worry about are (a) the
destination, and (b) the VoiceXML URI & parameters, than it is to deploy
an AS that does everything correctly in terms of SDP offer/answer,
Accept/Requires, PRACK, and so forth.  Even assuming that you're willing
to go out and get a decent AS implementation (which probably won't be
free) so that you don't have to deal with the details, we've now put an
extra element in the call path.  That's one more element that can fail
and that thus we have to worry about high availability on, one more set
of messages for every SIP transaction related to that call, and so
forth.

If you agree that there are non-mediactrl deployment scenarios in which
the overhead of an AS might not be called for, then you might accept the
need for an MS to send an outbound INVITE.  And after all, unless we
kill <transfer> with bridge=true, then the MS is going to need to
support sending INVITEs properly anyways.  However, even if you agreed
with this, you might still feel that a REFER was the wrong way to do
this.  

You could argue, for instance, that an HTTP or WS based approach to
providing such a capability is more appropriate than putting it on the
SIP interface.  There are valid reasons why this is true, but two
counter-points that led me to propose REFER in the first place:

* This is definitely a platform-level (not language-level) capability,
which every implementation provides, which we really have no other venue
to standardize;

* REFER can take advantage of SIP infrastructure for distributing
requests to available resources, whereas HTTP/WS-based interfaces would
be direct to the MS; if you had multiple MS instances you'd need
orthogonal load balancing of the HTTP/WS requests separately from the
balancing of inbound INVITE requests, despite that both requests are in
effect competing for the same resources.

These are the same reasons I presented the first time around as to why
outbound calls triggered via REFER made sense.

3.  Security.  Yes, on the surface of things, REFER looks dangerous if
you let evil.org send an unchecked REFER to the MS, triggering an
outbound call to some invalid number.

But there's *absolutely* no difference if evil.org sends an INVITE to
the MS, referring to a VoiceXML page containing a <transfer> with
bridge=true to exactly the same Request-URI.

The use of REFER here, IMO, presents no more of a security consideration
than the use of REFER anywhere.  We are not novel in proposing the use
of REFER outside a dialog, that option is explicitly stated in RFC 3515,
and we're not offering any reasons specific to a media server as to why
the use of REFER in this manner is problematic.

It is important here, of course, that supporting the receipt of a REFER
outside a dialog isn't mandatory; if implementations don't provide
adequate security, they aren't compelled to provide or to enable the
feature.

So, all in all, I don't think we've identified security related reasons
as to why this shouldn't be here.

For the reasons above, I actually do still favour supporting 5.2 -
though other issues have been noted with it that may need fixing.  I
don't believe there are any specific security issues at play here, and
while I am personally an advocate of the AS model, I have seen many
VoiceXML MS deployments where an AS is neither desired nor appropriate -
and draft-ietf-mediactrl-vxml is explicit in the intent of applying to
such environments (while obviously catering more to AS ones).

As noted at the beginning of this message, I am willing to yield to
group consensus, but I don't think we've yet identified valid reasons
why it should be axed (though, with nobody arguing for keeping it, many
may not have bothered stating their arguments :)).

Regards,

Mark.

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: December-20-07 6:15 PM
To: David Burke; Mark Scott
Cc: [email-masked]
Subject: RE: [MEDIACTRL] SIP-VXML - 5.2 REFER Mechanism for outbound
calls

<chair-hat off>

<chair-hat on>

Regards,
Dan

	RJ

		---
	RJ Auburn
	CTO, Voxeo Corporation
	tel:+1-407-418-1800

		
		
		Dave

			<contributor hat on>

			

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Dave Burke" <[email-masked]>
Date: Fri, 21 Dec 2007 12:15:53 +0000

Going back to RJ's original mail, the two issues he laid out in connection
with out-of-dialog REFERs were:
  (1) Security concerns
  (2) Non-conventional (no AS managed) call control

We could ameliorate security concerns by stating the MS SHOULD/MUST
implement authentication ( e.g. HTTP authentication or a transport layer
solution) on an out-of-dialog REFER. We would need to extend this to INVITE
too if transfer is supported for the reasons Mark points out.

However, point 2 is more compelling IMO. We have included SIP flows for
transfer because we have taken the pragmatic viewpoint that many networks
today deploy and will continue to deploy IVR solutions without an AS and use
the <transfer> element. (Typically in conjunction with PSTN gateways or
PBXs). We explicitly recommend against using transfer with an AS because the
AS cannot easily manage the ensuing flows. Therefore, it seems that offering
yet another mechanism to do call control which is not under the management
of an AS (i.e. this unsolicited REFER for outbound calls) would be contrary
to that recommendation, especially since there is a recommended alternative
(3pcc).

Finally, Eric has already pointed out that the Security Considerations
section needs to be updated to discuss transfer/billing issues. This thread
should serve as input.

Dave

On Dec 21, 2007 4:41 AM, Mark Scott <[email-masked]> wrote:

> From: Dan York [mailto: [email-masked]]
>                        On 12/3/07 3:31 PM, "RJ Auburn" < [email-masked]>
> wrote:
>
>                        > Folks,
>                        >
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential and proprietary information of Alcatel-Lucent and/or its
> affiliated entities. Access by the intended recipient only is authorized.
> Any liability arising from any party acting, or refraining from acting, on
> any information contained in this e-mail is hereby excluded. If you are not
> the intended recipient, please notify the sender immediately, destroy the
> original transmission and its attachments and do not disclose the contents
> to any other person, use it for any purpose, or store or copy the
> information in any medium. Copyright in this e-mail and any attachments
> belongs to Alcatel-Lucent and/or its affiliated entities.
>
>
>

---

From: "Mark Scott" <[email-masked]>
Date: Fri, 21 Dec 2007 06:05:26 -0800

On the security issue, I suppose that we could make statements to this
effect, although I'm not certain it would go all that far.  After all,
if you've got a scenario in which the MS is making an outbound toll call
out of some MG element somewhere, it'd be straightforward for evil.org
to just make the call via the MG directly if it had infrastructure
access.  That is to say, if you're assuming that the attacker has
unfettered access to run SIP UAs within a SIP deployment, then
preventing the attacker from bouncing off proxies (in the general sense
of the term) is sort of moot if they can just perform the attack
directly.  In reality you'd prevent direct and indirect attacks by
putting an adequate security policy around the MG or whatever resource
it was that you were trying to prevent the exploitation of.  I'm fine
with a note if we want to add it, though.

On the AS issue, the point I was trying to make was that "make outbound
call" and "handle inbound call" are both really basic use cases that
those in simple non-AS environments; the evidence of being that almost
all VoiceXML Media Servers (which act as standalone platforms and not
just as elements in an AS/MS environment) out there provide a
non-standardized mechanism for performing exactly this function.  I can
live with this function continuing to be non-standardized, and just
thought of this as probably the only opportunity we'll have to
standardize this widely implemented function.  I didn't imagine there
would be a lot of sympathy on the 'mediactrl' list for something like
this, though, given that the charter of the group is AS control over
media functions :-).

However, if I had better phrased the tertiary argument, I would probably
have said that even in an AS environment, the REFER option provides the
AS with a lightweight mechanism for outbound calls in which it is not
required to be on the call control path throughout the duration of the
call.  There are many useful scenarios, like proactive notification, in
which this could be the desired approach.  It looks like I may not be
completely off my rocker, nor even original, in suggesting the use of
REFER in this manner; the current version of 3GPP TS 23.228 (v8.30, but
I recalled this from the R6 specs) notes:

5.14.2      Service control based interactions between the MRFC and the
AS

... 

There are two approaches for the AS to control the sessions. In the
first, the AS uses 3rd party call control. The second approach uses the
SIP REFER method.

...

This isn't elaborated upon (in 23.228), and I can't tell for certain
whether that one line of text is in fact similar to the mechanism
proposed in 5.2.  I don't know the IMS specs well enough to even know
where to look for something that better defines this.  However, if you
look at Paul Kyzivat's comments on the 3PCC flow we did provide (on how
exactly to manipulate the SDP to still be compliant with offer/answer),
it certainly does highlight how non-trivial it can be to do the 3PCC
flow correctly and in compliance with the relevant standards.

Regards,

Mark.

From: Dave Burke [mailto:[email-masked]] 
Sent: December-21-07 7:16 AM
To: Mark Scott
Cc: Eric Burger; David Burke; [email-masked]
Subject: Re: [MEDIACTRL] SIP-VXML - 5.2 REFER Mechanism for outbound
calls

Going back to RJ's original mail, the two issues he laid out in
connection with out-of-dialog REFERs were:
  (1) Security concerns
  (2) Non-conventional (no AS managed) call control

We could ameliorate security concerns by stating the MS SHOULD/MUST
implement authentication ( e.g. HTTP authentication or a transport layer
solution) on an out-of-dialog REFER. We would need to extend this to
INVITE too if transfer is supported for the reasons Mark points out. 

However, point 2 is more compelling IMO. We have included SIP flows for
transfer because we have taken the pragmatic viewpoint that many
networks today deploy and will continue to deploy IVR solutions without
an AS and use the <transfer> element. (Typically in conjunction with
PSTN gateways or PBXs). We explicitly recommend against using transfer
with an AS because the AS cannot easily manage the ensuing flows.
Therefore, it seems that offering yet another mechanism to do call
control which is not under the management of an AS ( i.e. this
unsolicited REFER for outbound calls) would be contrary to that
recommendation, especially since there is a recommended alternative
(3pcc).

Finally, Eric has already pointed out that the Security Considerations
section needs to be updated to discuss transfer/billing issues. This
thread should serve as input. 

Dave

Hi Everyone,

to standardize;

Regards,

Mark.

-----Original Message----- 
From: Eric Burger [mailto:[email-masked]]
Sent: December-20-07 6:15 PM
To: David Burke; Mark Scott
Cc: [email-masked]
Subject: RE: [MEDIACTRL] SIP-VXML - 5.2 REFER Mechanism for outbound
calls

<chair-hat off>

<chair-hat on>

Regards,
Dan

       RJ

               ---
       RJ Auburn
       CTO, Voxeo Corporation 
       tel:+1-407-418-1800

               Dave

                       <contributor hat on> 

                       _______________________________________________ 
                       MEDIACTRL mailing list
                       [email-masked]
                        https://www1.ietf.org/mailman/listinfo/mediactrl
<https://www1.ietf.org/mailman/listinfo/mediactrl> 
                       Supplemental Web Site:
                       http://www.standardstrack.com/ietf/mediactrl 

       _______________________________________________
       MEDIACTRL mailing list
       [email-masked]
        https://www1.ietf.org/mailman/listinfo/mediactrl
<https://www1.ietf.org/mailman/listinfo/mediactrl> 
       Supplemental Web Site:
       http://www.standardstrack.com/ietf/mediactrl

------------------------------------------------------------------------
------------------------------------------- 
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is
authorized. Any liability arising from any party acting, or refraining
from acting, on any information contained in this e-mail is hereby
excluded. If you are not the intended recipient, please notify the
sender immediately, destroy the original transmission and its
attachments and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.