Joe Zebarth | 1 Dec 19:28 2004

Comments on draft-ietf-sipping-app-interaction-framework-03

Colleagues

The following are a few comments that I have with respect to draft-ietf-sipping-app-interaction-framework-03.

Would it be worth noting in the abstract and/or the introduction that this document is providing IANA registration for a new "SIP Option Tag" and a new "Header Field Parameter"?

Is there an inconsistency between Figure 1 which shows the "user interface" on the network side of the user device and the definition "Focusless User Interface: A user interface which has no ability to perform focus determination.  An example of a focusless user interface is a keypad on a telephone."  So if the definition is correct should Figure 1 show a "user interface" on the user side of the "user device".  If so, should we consider a new term that is less confusing for the functionality currently labeled as "user interface" in Figure 1?

In the definition for "Barge-In", possibly the last sentence should come to the front.  Minor rewording would be required if this is done.

On page 18 the words "the markup waits".  I observe that the term "markup" is not in the definitions section, should it be added or is there a better term for this functionality?

 


Kindest Regards

Joe Zebarth
ATI Strategic Standards
Nortel Networks (Canada)
Phone: +1 613 765 8481
ESN:    6+395 8481
Fax:     +1 613 763 2697
ESN:    6+393 2697
http://www.nortelnetworks.com


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Even, Roni | 2 Dec 14:06 2004
Picon

RE: Conference speaker control

Hi,
What about sending media over tcp based on the comedia draft, this is
not RTP.
Roni

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
Behalf Of Brian Rosen
Sent: Tuesday, November 30, 2004 9:19 PM
To: Even, Roni; 'Magnus Westerlund'
Cc: 'sipping'
Subject: RE: [Sipping] Conference speaker control

Brian

There is no requirement to use RTP, there is merely no existing
alternative.

Brian

> -----Original Message-----
> From: Even, Roni [mailto:roni.even <at> polycom.co.il]
> Sent: Tuesday, November 30, 2004 12:59 PM
> To: Brian Rosen; Magnus Westerlund
> Cc: sipping
> Subject: RE: [Sipping] Conference speaker control
> 
> Brian,
> I know it is SIPPINg and I mentioned that we may extend the conference
> package in XCON.
> I am still not sure about the ssrc. Does SIP allows only RTP sessions.
As
> far as I know there is no such assumption in SDP.
> Roni Even
> 
> ________________________________
> 
> From: sipping-bounces <at> ietf.org on behalf of Brian Rosen
> Sent: Tue 11/30/2004 4:02 PM
> To: Even, Roni; 'Magnus Westerlund'
> Cc: 'sipping'
> Subject: RE: [Sipping] Conference speaker control
> 
> 
> 
> Roni
> 
> This is SIPPING.  If we have PSTN participants in a conference, they
come
> from some kind of gateway and use SIP signaling.  AFAIK, there is no
way
> with current IETF protocols to have a conference where the
participants
> are
> anything but SIP endpoints using RTP for media streams.
> 
> You might ask over in the XCON list whether anyone thinks trying to
use
> XCON
> protocols to control a PSTN mixer without RTP is in scope.  XCON is
not
> limited to SIP, but I'm not sure such a case is something we should be
> worried about.  It's clearly not something in SIPPING's charter.
> 
> Brian
> 
> > -----Original Message-----
> > From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
> Behalf
> > Of Even, Roni
> > Sent: Tuesday, November 30, 2004 3:46 AM
> > To: Magnus Westerlund
> > Cc: sipping
> > Subject: RE: [Sipping] Conference speaker control
> >
> > Magnus,
> > The problem you stated is correct but this is not what I meant. In
XCON
> > conference server can be composed of a conference/media policy
server
> > and a focus that can be an application server that handle conference
> > policy and some web collaboration while the mixer is a PSTN bridge.
> > A participant in such a conference is using a PSTN phone and a PC
for
> > web collaboration and conference control. The PC can subscribe to
the
> > conference package but since the audio is PSTN there are no RTP or
SSRC.
> > Even for IP conferencing making an assumption that all streams in a
> > conference are RTP streams is not always right, so ssrc cannot be
used
> > to describe who is sourcing each stream in an application that uses
a
> > mix of RTP and non RTP streams.
> > Roni Even
> >
> > -----Original Message-----
> > From: Magnus Westerlund [mailto:magnus.westerlund <at> ericsson.com]
> > Sent: Monday, November 29, 2004 5:45 PM
> > To: Even, Roni
> > Cc: sipping
> > Subject: Re: [Sipping] Conference speaker control
> >
> > Hi Roni,
> >
> > Lets see if I understand this correctly. You are worried about PSTN
or
> > other gateways that are receiving more than one source over the same
> > circuit and in which cases the gateway can't separate the different
> > sources within the CS to IP gateway. As long as the PSTN gateway
> > receives the different circuit switched sources in the same
conference
> > on different circuits, it is able to assign them different SSRCs and
> > IDs.
> >
> > If the above is the case, how would adding any other mechanism help?
The
> >
> > gateway can still not identify the original sources, or am I
> > misunderstanding something about the setup?
> >
> > My understanding of the setup you are concern is:
> >
> >
> > CS1 --\
> >         -> CS Bridge -> Gateway ->  IP Conf Bridge -> Client 3
> > CS2 --/                  ^               ^
> >                           |               |
> >                          CS5           Client 4
> >
> > In this case Client 3 and 4 would not be able to determine that what
is
> > beyond the gateway is in fact three client. CS1 and CS2 will be
bunched
> > together under one source identifier? While CS5 can be identified as
it
> > connects directly with the gateway and uses a separate CS line into
the
> > gateway, thus allowing the gateway to give them separate IDs.
> >
> > It should also not be a problem if the protocol used on the CS side
> > provides identities, then the gateway can provide different
identifiers
> > for the different CS side users.
> >
> > Cheers
> >
> > Magnus
> >
> > Even, Roni wrote:
> >
> > > Magnus,
> > > I am not saying that RTP using SSRC does not have a mechanism to
> > > identify the source of the streams. What I am trying to say is
that we
> > > are not talking about a pure RTP mixer but we are talking about a
SIP
> > > based conferencing server and in XCON the scope is even wider, it
may
> > be
> > > a PSTN bridge bellow.
> > > So first of all there is no requirement defined that the mixer in
SIP
> > > conferencing or XCON should be a RTP mixer per RFC3550. Even if we
do
> > it
> > > for SIPPING then we will have a problem for PSTN Bridge (example
of
> > > usage if for audio-graphic conference) and it will break for XCON.
> > > Roni Even
> >
> >
> > --
> >
> > Magnus Westerlund
> >
> > Multimedia Technologies, Ericsson Research EAB/TVA/A
> >
----------------------------------------------------------------------
> > Ericsson AB                | Phone +46 8 4048287
> > Torshamsgatan 23           | Fax   +46 8 7575550
> > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors <at> cs.columbia.edu for questions on current sip
> > Use sip <at> ietf.org for new developments of core SIP
> >
> 
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP
> 
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Magnus Westerlund | 2 Dec 14:49 2004
Picon

Re: Conference speaker control

Hi Roni,

Even, Roni wrote:

> Hi,
> What about sending media over tcp based on the comedia draft, this is
> not RTP.

It may or it may not. Any media over TCP will need some type of framing, 
either if it is a HTTP download of a progressive media stream, or if it 
is RTP over TCP. There is actually a generic RTP over TCP proposal 
including protocol identifier for SDP in:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-framing-contrans-03.txt

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

David R Oran | 2 Dec 21:22 2004
Picon

Re: Conference speaker control

Huh? There's a spec for RTP over TCP.

On Dec 2, 2004, at 8:06 AM, Even, Roni wrote:

> Hi,
> What about sending media over tcp based on the comedia draft, this is
> not RTP.
> Roni
>
> -----Original Message-----
> From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
> Behalf Of Brian Rosen
> Sent: Tuesday, November 30, 2004 9:19 PM
> To: Even, Roni; 'Magnus Westerlund'
> Cc: 'sipping'
> Subject: RE: [Sipping] Conference speaker control
>
> Brian
>
> There is no requirement to use RTP, there is merely no existing
> alternative.
>
> Brian
>
>
>> -----Original Message-----
>> From: Even, Roni [mailto:roni.even <at> polycom.co.il]
>> Sent: Tuesday, November 30, 2004 12:59 PM
>> To: Brian Rosen; Magnus Westerlund
>> Cc: sipping
>> Subject: RE: [Sipping] Conference speaker control
>>
>> Brian,
>> I know it is SIPPINg and I mentioned that we may extend the conference
>> package in XCON.
>> I am still not sure about the ssrc. Does SIP allows only RTP sessions.
> As
>> far as I know there is no such assumption in SDP.
>> Roni Even
>>
>> ________________________________
>>
>> From: sipping-bounces <at> ietf.org on behalf of Brian Rosen
>> Sent: Tue 11/30/2004 4:02 PM
>> To: Even, Roni; 'Magnus Westerlund'
>> Cc: 'sipping'
>> Subject: RE: [Sipping] Conference speaker control
>>
>>
>>
>> Roni
>>
>> This is SIPPING.  If we have PSTN participants in a conference, they
> come
>> from some kind of gateway and use SIP signaling.  AFAIK, there is no
> way
>> with current IETF protocols to have a conference where the
> participants
>> are
>> anything but SIP endpoints using RTP for media streams.
>>
>> You might ask over in the XCON list whether anyone thinks trying to
> use
>> XCON
>> protocols to control a PSTN mixer without RTP is in scope.  XCON is
> not
>> limited to SIP, but I'm not sure such a case is something we should be
>> worried about.  It's clearly not something in SIPPING's charter.
>>
>> Brian
>>
>>> -----Original Message-----
>>> From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
>> Behalf
>>> Of Even, Roni
>>> Sent: Tuesday, November 30, 2004 3:46 AM
>>> To: Magnus Westerlund
>>> Cc: sipping
>>> Subject: RE: [Sipping] Conference speaker control
>>>
>>> Magnus,
>>> The problem you stated is correct but this is not what I meant. In
> XCON
>>> conference server can be composed of a conference/media policy
> server
>>> and a focus that can be an application server that handle conference
>>> policy and some web collaboration while the mixer is a PSTN bridge.
>>> A participant in such a conference is using a PSTN phone and a PC
> for
>>> web collaboration and conference control. The PC can subscribe to
> the
>>> conference package but since the audio is PSTN there are no RTP or
> SSRC.
>>> Even for IP conferencing making an assumption that all streams in a
>>> conference are RTP streams is not always right, so ssrc cannot be
> used
>>> to describe who is sourcing each stream in an application that uses
> a
>>> mix of RTP and non RTP streams.
>>> Roni Even
>>>
>>> -----Original Message-----
>>> From: Magnus Westerlund [mailto:magnus.westerlund <at> ericsson.com]
>>> Sent: Monday, November 29, 2004 5:45 PM
>>> To: Even, Roni
>>> Cc: sipping
>>> Subject: Re: [Sipping] Conference speaker control
>>>
>>> Hi Roni,
>>>
>>> Lets see if I understand this correctly. You are worried about PSTN
> or
>>> other gateways that are receiving more than one source over the same
>>> circuit and in which cases the gateway can't separate the different
>>> sources within the CS to IP gateway. As long as the PSTN gateway
>>> receives the different circuit switched sources in the same
> conference
>>> on different circuits, it is able to assign them different SSRCs and
>>> IDs.
>>>
>>> If the above is the case, how would adding any other mechanism help?
> The
>>>
>>> gateway can still not identify the original sources, or am I
>>> misunderstanding something about the setup?
>>>
>>> My understanding of the setup you are concern is:
>>>
>>>
>>> CS1 --\
>>>         -> CS Bridge -> Gateway ->  IP Conf Bridge -> Client 3
>>> CS2 --/                  ^               ^
>>>                           |               |
>>>                          CS5           Client 4
>>>
>>> In this case Client 3 and 4 would not be able to determine that what
> is
>>> beyond the gateway is in fact three client. CS1 and CS2 will be
> bunched
>>> together under one source identifier? While CS5 can be identified as
> it
>>> connects directly with the gateway and uses a separate CS line into
> the
>>> gateway, thus allowing the gateway to give them separate IDs.
>>>
>>> It should also not be a problem if the protocol used on the CS side
>>> provides identities, then the gateway can provide different
> identifiers
>>> for the different CS side users.
>>>
>>> Cheers
>>>
>>> Magnus
>>>
>>> Even, Roni wrote:
>>>
>>>> Magnus,
>>>> I am not saying that RTP using SSRC does not have a mechanism to
>>>> identify the source of the streams. What I am trying to say is
> that we
>>>> are not talking about a pure RTP mixer but we are talking about a
> SIP
>>>> based conferencing server and in XCON the scope is even wider, it
> may
>>> be
>>>> a PSTN bridge bellow.
>>>> So first of all there is no requirement defined that the mixer in
> SIP
>>>> conferencing or XCON should be a RTP mixer per RFC3550. Even if we
> do
>>> it
>>>> for SIPPING then we will have a problem for PSTN Bridge (example
> of
>>>> usage if for audio-graphic conference) and it will break for XCON.
>>>> Roni Even
>>>
>>>
>>> --
>>>
>>> Magnus Westerlund
>>>
>>> Multimedia Technologies, Ericsson Research EAB/TVA/A
>>>
> ----------------------------------------------------------------------
>>> Ericsson AB                | Phone +46 8 4048287
>>> Torshamsgatan 23           | Fax   +46 8 7575550
>>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
>>>
>>> _______________________________________________
>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP
>>> Use sip-implementors <at> cs.columbia.edu for questions on current sip
>>> Use sip <at> ietf.org for new developments of core SIP
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use sip-implementors <at> cs.columbia.edu for questions on current sip
>> Use sip <at> ietf.org for new developments of core SIP
>>
>>
>>
>
>
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran <at> cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Even, Roni | 3 Dec 09:39 2004
Picon

RE: Conference speaker control

Hi, 
This is from the comedia draft, is it RTP, it does not say so.

           m=image 54111 TCP t38
           c=IN IP4 192.0.2.2
           a=setup:passive
           a=connection:new

Roni

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
Behalf Of David R Oran
Sent: Thursday, December 02, 2004 10:23 PM
To: Even, Roni
Cc: Magnus Westerlund; sipping
Subject: Re: [Sipping] Conference speaker control

Huh? There's a spec for RTP over TCP.

On Dec 2, 2004, at 8:06 AM, Even, Roni wrote:

> Hi,
> What about sending media over tcp based on the comedia draft, this is
> not RTP.
> Roni
>
> -----Original Message-----
> From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
> Behalf Of Brian Rosen
> Sent: Tuesday, November 30, 2004 9:19 PM
> To: Even, Roni; 'Magnus Westerlund'
> Cc: 'sipping'
> Subject: RE: [Sipping] Conference speaker control
>
> Brian
>
> There is no requirement to use RTP, there is merely no existing
> alternative.
>
> Brian
>
>
>> -----Original Message-----
>> From: Even, Roni [mailto:roni.even <at> polycom.co.il]
>> Sent: Tuesday, November 30, 2004 12:59 PM
>> To: Brian Rosen; Magnus Westerlund
>> Cc: sipping
>> Subject: RE: [Sipping] Conference speaker control
>>
>> Brian,
>> I know it is SIPPINg and I mentioned that we may extend the
conference
>> package in XCON.
>> I am still not sure about the ssrc. Does SIP allows only RTP
sessions.
> As
>> far as I know there is no such assumption in SDP.
>> Roni Even
>>
>> ________________________________
>>
>> From: sipping-bounces <at> ietf.org on behalf of Brian Rosen
>> Sent: Tue 11/30/2004 4:02 PM
>> To: Even, Roni; 'Magnus Westerlund'
>> Cc: 'sipping'
>> Subject: RE: [Sipping] Conference speaker control
>>
>>
>>
>> Roni
>>
>> This is SIPPING.  If we have PSTN participants in a conference, they
> come
>> from some kind of gateway and use SIP signaling.  AFAIK, there is no
> way
>> with current IETF protocols to have a conference where the
> participants
>> are
>> anything but SIP endpoints using RTP for media streams.
>>
>> You might ask over in the XCON list whether anyone thinks trying to
> use
>> XCON
>> protocols to control a PSTN mixer without RTP is in scope.  XCON is
> not
>> limited to SIP, but I'm not sure such a case is something we should
be
>> worried about.  It's clearly not something in SIPPING's charter.
>>
>> Brian
>>
>>> -----Original Message-----
>>> From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
>> Behalf
>>> Of Even, Roni
>>> Sent: Tuesday, November 30, 2004 3:46 AM
>>> To: Magnus Westerlund
>>> Cc: sipping
>>> Subject: RE: [Sipping] Conference speaker control
>>>
>>> Magnus,
>>> The problem you stated is correct but this is not what I meant. In
> XCON
>>> conference server can be composed of a conference/media policy
> server
>>> and a focus that can be an application server that handle conference
>>> policy and some web collaboration while the mixer is a PSTN bridge.
>>> A participant in such a conference is using a PSTN phone and a PC
> for
>>> web collaboration and conference control. The PC can subscribe to
> the
>>> conference package but since the audio is PSTN there are no RTP or
> SSRC.
>>> Even for IP conferencing making an assumption that all streams in a
>>> conference are RTP streams is not always right, so ssrc cannot be
> used
>>> to describe who is sourcing each stream in an application that uses
> a
>>> mix of RTP and non RTP streams.
>>> Roni Even
>>>
>>> -----Original Message-----
>>> From: Magnus Westerlund [mailto:magnus.westerlund <at> ericsson.com]
>>> Sent: Monday, November 29, 2004 5:45 PM
>>> To: Even, Roni
>>> Cc: sipping
>>> Subject: Re: [Sipping] Conference speaker control
>>>
>>> Hi Roni,
>>>
>>> Lets see if I understand this correctly. You are worried about PSTN
> or
>>> other gateways that are receiving more than one source over the same
>>> circuit and in which cases the gateway can't separate the different
>>> sources within the CS to IP gateway. As long as the PSTN gateway
>>> receives the different circuit switched sources in the same
> conference
>>> on different circuits, it is able to assign them different SSRCs and
>>> IDs.
>>>
>>> If the above is the case, how would adding any other mechanism help?
> The
>>>
>>> gateway can still not identify the original sources, or am I
>>> misunderstanding something about the setup?
>>>
>>> My understanding of the setup you are concern is:
>>>
>>>
>>> CS1 --\
>>>         -> CS Bridge -> Gateway ->  IP Conf Bridge -> Client 3
>>> CS2 --/                  ^               ^
>>>                           |               |
>>>                          CS5           Client 4
>>>
>>> In this case Client 3 and 4 would not be able to determine that what
> is
>>> beyond the gateway is in fact three client. CS1 and CS2 will be
> bunched
>>> together under one source identifier? While CS5 can be identified as
> it
>>> connects directly with the gateway and uses a separate CS line into
> the
>>> gateway, thus allowing the gateway to give them separate IDs.
>>>
>>> It should also not be a problem if the protocol used on the CS side
>>> provides identities, then the gateway can provide different
> identifiers
>>> for the different CS side users.
>>>
>>> Cheers
>>>
>>> Magnus
>>>
>>> Even, Roni wrote:
>>>
>>>> Magnus,
>>>> I am not saying that RTP using SSRC does not have a mechanism to
>>>> identify the source of the streams. What I am trying to say is
> that we
>>>> are not talking about a pure RTP mixer but we are talking about a
> SIP
>>>> based conferencing server and in XCON the scope is even wider, it
> may
>>> be
>>>> a PSTN bridge bellow.
>>>> So first of all there is no requirement defined that the mixer in
> SIP
>>>> conferencing or XCON should be a RTP mixer per RFC3550. Even if we
> do
>>> it
>>>> for SIPPING then we will have a problem for PSTN Bridge (example
> of
>>>> usage if for audio-graphic conference) and it will break for XCON.
>>>> Roni Even
>>>
>>>
>>> --
>>>
>>> Magnus Westerlund
>>>
>>> Multimedia Technologies, Ericsson Research EAB/TVA/A
>>>
> ----------------------------------------------------------------------
>>> Ericsson AB                | Phone +46 8 4048287
>>> Torshamsgatan 23           | Fax   +46 8 7575550
>>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
>>>
>>> _______________________________________________
>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP
>>> Use sip-implementors <at> cs.columbia.edu for questions on current sip
>>> Use sip <at> ietf.org for new developments of core SIP
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use sip-implementors <at> cs.columbia.edu for questions on current sip
>> Use sip <at> ietf.org for new developments of core SIP
>>
>>
>>
>
>
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran <at> cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Magnus Westerlund | 3 Dec 10:10 2004
Picon

Re: Conference speaker control

Even, Roni wrote:
> Hi,
> This is from the comedia draft, is it RTP, it does not say so.
> 
>            m=image 54111 TCP t38
>            c=IN IP4 192.0.2.2
>            a=setup:passive
>            a=connection:new
> 
> Roni

No, that is clearly T38 over TCP which has a mode that is not RTP, 
however if you look in the RTP over TCP draft:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-framing-contrans-03.txt

You can find the following SDP:
v=0
o=first 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
c=IN IP4 192.0.2.105
m=audio 9 TCP/RTP/AVP 11
a=setup:active
a=connid:1

It is also this draft that register the RTP over TCP SDP protocol 
identifier.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Internet-Drafts | 3 Dec 13:15 2004
Picon

I-D ACTION:draft-ietf-sipping-uri-list-conferencing-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: Conference Establishment Using Request-Contained
                          Lists in the Session Initiation Protocol (SIP)
	Author(s)	: G. Camarillo, A. Johnston
	Filename	: draft-ietf-sipping-uri-list-conferencing-02.txt
	Pages		: 9
	Date		: 2004-12-2
	
This document describes how to create a conference using SIP URI-list
   services. In particular, we describe a mechanism that allows a client
   to provide a conference server with the initial list of participants
   using an INVITE-contained URI-list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-conferencing-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-uri-list-conferencing-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-uri-list-conferencing-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 153 bytes
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Internet-Drafts | 3 Dec 13:15 2004
Picon

I-D ACTION:draft-ietf-sipping-uri-list-message-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: Multiple-Recipient MESSAGE Requests in the Session
                          Initiation Protocol (SIP)
	Author(s)	: M. Garcia-Martin, G. Camarillo
	Filename	: draft-ietf-sipping-uri-list-message-02.txt
	Pages		: 20
	Date		: 2004-12-2
	
This document specifies how to request a SIP URI-list service to send
   a copy of a MESSAGE to a set of destinations.  The client sends a SIP
   MESSAGE request with a URI-list to the MESSAGE URI-list service,
   which sends a similar MESSAGE request to each of the URIs included in
   the list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-message-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-uri-list-message-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-uri-list-message-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 148 bytes
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Internet-Drafts | 3 Dec 13:15 2004
Picon

I-D ACTION:draft-ietf-sipping-multiple-refer-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: Refering to Multiple Resources in the Session
                          Initiation Protocol (SIP)
	Author(s)	: G. Camarillo, et al.
	Filename	: draft-ietf-sipping-multiple-refer-02.txt
	Pages		: 12
	Date		: 2004-12-2
	
This document defines extensions to the SIP REFER method so that this
   method can be used to refer servers to multiple resources.  These
   extensions include the use of pointers to Uniform Resource Identifier
   (URI)-lists in the Refer-To header field and the "multiple-refer" SIP
   option-tag.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-multiple-refer-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-multiple-refer-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-multiple-refer-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 146 bytes
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Internet-Drafts | 3 Dec 13:15 2004
Picon

I-D ACTION:draft-ietf-sipping-uri-services-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: Requirements and Framework for Session Initiation 
                          Protocol (SIP)Uniform Resource Identifier (URI)-List 
                          Services
	Author(s)	: G. Camarillo, A. Roach
	Filename	: draft-ietf-sipping-uri-services-02.txt
	Pages		: 11
	Date		: 2004-12-2
	
This document describes the need for SIP URI-list services and
   provides requirements for their invocation.  Additionaly, it defines
   a framework for SIP URI-List services which includes security
   considerations applicable to these services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-services-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-uri-services-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-uri-services-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 144 bytes
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Gmane