headers
Nils Henrik Lorentzen | 1 Aug 2002 08:52
Picon

Re: Signaling FIR/Freeze in SIP

On Wednesday 31 July 2002 12:38, you wrote:

> 1. Sending a freeze a couple of times may cause a problem. The freeze
> requests are sent from the MCU and not from the encoding endpoints while
> the full picture is coming from the endpoint. So what happens if a freeze
> arrives after the intra frame with the freeze release code. The decoder
> will freeze, he has no way to know if the freeze was for a switch in the
> past or for a switch in future.

As mentioned in anther post,  this problem could probably be solved
by sending the RTP's timestamp/sequence number at the time of sending
the first freeze. Possible this introduces more problems though.

> 2. The customers of the video conferencing MCUs do not like to have an ugly
> video during the video switch, so we need a solution which will be more
> reliable.

If we can do retransmits of freeze, then in my opinion loss of all freeze
packets would be rare enough to justify best-effort sending.

> So how do you see inter-op between H.323 and SIP or is this not an issue

It sure is an issue.  Making old H.323 endpoints support new RTCP packets
would take time or more likely never happen, so the only possibility would
be to also handle RTCP/RTP in a H.323/SIP GW. I agree this speaks
strongly against an RTCP based solution.

> > If an endpoint sends the exact same SDP to another endpoint
> > several times in
> > sequence, only the first SDP arriving at remote should trigger any
(Continue reading)

Permalink | Reply | 0 comments |
headers
Orit Levin | 1 Aug 2002 15:22
Favicon

RE: Signaling FIR/Freeze in SIP

Nils and all the rest!
I am replying to the whole thread being exchanged today so far.
I agree with the bottom line conclusion (although my reasoning may be
slightly different).

Since, there is no agreement to standardize the required primitives within
the old SDP and taking into account all the drawbacks of such a solution,
there is no point pursuing this direction.

Instead, we need two things:
1. Working on a new point-to-point media control protocol
2. Agree on a doable way (such as INFO) to convey the required primitives in
the call signaling path. It doesn't have to be a standard. 

For all the practical reasons, multimedia vendors will need to support both.

We (as RADVISION together with its partners) already have a simple
extensible XML scheme to be conveyed in the INFO messages for exactly this
purpose. I plan to publish it as an IETF draft shortly.

BR,
Orit Levin
Chief Architect
RADVISION Inc.
Tel:  +1.201.689.6330

 -----Original Message-----
From: 	Nils Henrik Lorentzen [mailto:nhl <at> tandberg.no] 
Sent:	Wednesday, July 31, 2002 6:04 AM
To:	mmusic <at> ietf.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mahesh Shankar | 2 Aug 2002 21:48
Picon
Favicon

RTSP SETUP and ANNOUNCE requests

Hello,

I was looking at the RTSP rfc, and I have a couple of questions:

1. Can an RTSP client request a PLAY session to be unicast to a host
other than itself ?
2. If so, would sending a SETUP message followed by an ANNOUNCE message
with the SDP information for the media-receiving-host be the way to do
it ?

I would appreciate it if someone could shed some light on this.

TIA.

-M
Permalink | Reply | 0 comments |
headers
MONFORT Patrick FTRD/DMI/ISS | 5 Aug 2002 10:20

RE: video media control draft

Hello,

Th draft I mentioned in a previous mail
"draft-koskelainen-sdp263-02.txt" deals with SIZE and OPTIONS of video
codec. How do you propose the manage them during a call.

All thoses things are in the stream itself, but, a Video UA need a way
to express them during the initiation of the call and to control them
during the call.

Thanks,

Patrick,

-----Original Message-----
From: Colin Perkins [mailto:csp <at> isi.edu]
Sent: vendredi 26 juillet 2002 19:46
To: MONFORT Patrick FTRD/DMI/ISS
Cc: mmusic <at> ietf.org
Subject: Re: [MMUSIC] video media control draft 

I'm not sure we agree on the list of other things are needed. Some form
of
fast intro request, certainly, but what else? Freeze has been discussed,
but that may not be necessary. Are there others?

Colin

--> "MONFORT Patrick FTRD/DMI/ISS" writes:
>Yes, that would help.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kathy Kwan | 3 Aug 2002 01:20

Port changeability in response to Invite -- expected behavior?

To the SIP/MMUSIC community,

 

I was looking at the method proposed by Rosenberg and Schulzrinne in the IETF Internet Draft entitled "Models for Multiparty Conferencing in SIP" (dated July 2002, expires Jan 2003), Section 7, entitled "Centralized Signaling, Distributed Media".    This method describes the conferencing case where a server controls the SIP connections with all participants, and uses third party call control to enable media connections to go directly between the participants.   Hence, the signaling is centralized, but media is distributed.  In order for the method to work, an inherent assumption is made that the original ports do not change in the response to an Invite.  Two examples of this assumption are shown in the call flow diagram of "Centralized Signaling, Distributed Media" Figure 7:

 

(1)      If a participant is taken off hold, the participant cannot change its ports in its response.

 

In Figure 7, participant  D is taken off hold in the very last Invite transaction between D and the server.   It is assumed that D does not change its ports D1,D2, and D3 in its Invite 200 OK response.  

 

(Perhaps there is a way to interleave invites using provisional responses that could fix this particular case, but if that exists, the response could be delayed by as long as it takes to receive the responses from all other participants in the conference.)

 

(2)      If a participant receives a re-Invite for any reason, the participant must maintain its original offered ports in the response.

 

In Figure 7, parties A, B and C are assumed to not change their original ports when they receive a re-Invite from the server asking for an additional port for D.   According to Figure 7, A, B, and C are not put on hold when D arrives, so this case is distinct from (1) above.    

 

My questions are:

 

(3)      What assumptions can be made about the ports being able to change in the response to an Invite?    Is there documentation of this in any RFCs?   

 

Perhaps a media attribute could be used to request that the ports don't change if it is not already implied in either of the cases above?

 

(4)      There are two ways to convey hold described below.   Is the expectation for port behavior the same for both cases of hold?

 

The original way to convey hold is to set the IP address to 0.0.0.0.  This case does not require RTCP to be sent during the hold period.   A new method to convey hold is to use the media attributes "a=inactive", "a=sendonly" or "a=recvonly", depending on the direction of the hold.  Because of the different implications for the hold methods, particularly for RTCP, I am asking this question with both methods in mind.

 

Thank you in advance for your comments.

 

Regards,

Kathy Kwan

Interval Media

 

Permalink | Reply | 2 comments |
headers
Petri K. Koskelainen | 5 Aug 2002 17:44

video media control draft


Hi,

That draft works only for H.263 codec so it is not
a general solution. Moreover, using SDP a line 
to express options (or group of options and 
complex restrictions) is very difficult.

In the setup phase, you could advertize your
codec capabilities (in SDP), so it
is possible to change options during a call
without further signaling. But I guess
it makes sense to inform also signaling level
about the change (since e.g. bandwidth requirement 
may change considerably if you change options).

Petri

-----------------------------

Hello,

Th draft I mentioned in a previous mail
"draft-koskelainen-sdp263-02.txt" deals with SIZE and OPTIONS of video
codec. How do you propose the manage them during a call.

All thoses things are in the stream itself, but, a Video UA need a way
to express them during the initiation of the call and to control them
during the call.

Thanks,

Patrick,
Permalink | Reply | 0 comments |
headers
MONFORT Patrick FTRD/DMI/ISS | 5 Aug 2002 20:08

RE: video media control draft

Hello,

The draft allows to express H263, H263+ options, but also the format of
the picture (whatever codec you use).

I agree with you saying that simple SDP line is not the best way, but
expressing video capabilities (options, format), without any SDP info
(which is actually the case or else I've missed something) is also very
difficult to do.

To me, the setup phase is one thing, but controlling the media once the
communication is important (someone may want to change the format of the
other's party encoder for example). And yes, if something changes
(option, but once again format), the bandwith may be impacted, and so,
as you mentioned, it makes sense to have signaling to do that.

Patrick,

-----Original Message-----
From: Petri K. Koskelainen [mailto:petkos <at> cs.columbia.edu]
Sent: lundi 5 aout 2002 17:45
To: mmusic <at> ietf.org
Subject: [MMUSIC] video media control draft

Hi,

That draft works only for H.263 codec so it is not
a general solution. Moreover, using SDP a line 
to express options (or group of options and 
complex restrictions) is very difficult.

In the setup phase, you could advertize your
codec capabilities (in SDP), so it
is possible to change options during a call
without further signaling. But I guess
it makes sense to inform also signaling level
about the change (since e.g. bandwidth requirement 
may change considerably if you change options).

Petri

-----------------------------

Hello,

Th draft I mentioned in a previous mail
"draft-koskelainen-sdp263-02.txt" deals with SIZE and OPTIONS of video
codec. How do you propose the manage them during a call.

All thoses things are in the stream itself, but, a Video UA need a way
to express them during the initiation of the call and to control them
during the call.

Thanks,

Patrick,

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 0 comments |
headers
Colin Perkins | 5 Aug 2002 22:08
Picon
Favicon

Re: video media control draft

That would seem to be something for the signalling protocol, since it
changes the media format. It's not clear to me that this information
can cleanly be siganlled in SDP though, it may be better suited to an
SDPng expression?

Colin

--> "MONFORT Patrick FTRD/DMI/ISS" writes:
>Hello,
>
>Th draft I mentioned in a previous mail
>"draft-koskelainen-sdp263-02.txt" deals with SIZE and OPTIONS of video
>codec. How do you propose the manage them during a call.
>
>All thoses things are in the stream itself, but, a Video UA need a way
>to express them during the initiation of the call and to control them
>during the call.
>
>Thanks,
>
>Patrick,
>
>
>-----Original Message-----
>From: Colin Perkins [mailto:csp <at> isi.edu]
>Sent: vendredi 26 juillet 2002 19:46
>To: MONFORT Patrick FTRD/DMI/ISS
>Cc: mmusic <at> ietf.org
>Subject: Re: [MMUSIC] video media control draft 
>
>
>I'm not sure we agree on the list of other things are needed. Some form
>of
>fast intro request, certainly, but what else? Freeze has been discussed,
>but that may not be necessary. Are there others?
>
>Colin
>
>
>
>--> "MONFORT Patrick FTRD/DMI/ISS" writes:
>>Yes, that would help.
>>
>>As other things are needed, would it be possible to have/imagine an
>>attribute in the SDP (associated to media or the session) that can
>>manage all the "control" aspect of media. UA could listen on this
>>"control" port to receive command from other(s) party(ies).
>>
>>Or else, if we don't want to manage a new port, I think we will have a
>>new SIP message that will carry a new SDP with constraints on it (like
>>to update only attribute of the declared media) ?
>>
>>
>>-----Original Message-----
>>From: Colin Perkins [mailto:csp <at> isi.edu]
>>Sent: mercredi 24 juillet 2002 22:38
>>To: MONFORT Patrick FTRD/DMI/ISS
>>Cc: Joerg Ott; Orit Levin; mmusic <at> ietf.org
>>Subject: Re: [MMUSIC] video media control draft 
>>
>>
>>--> "MONFORT Patrick FTRD/DMI/ISS" writes:
>>...deleted...
>>>Regarding the control, RFC 2032 (which describes RTCP packet for
>>>IntraRequest) can't be deployed. The reason is that these RTCP packets
>>>are not sent to the 'standard' RTCP Port.
>>>
>>>Here are the text taken from RFC 2032, that explains this issue
>>(section
>>>5.1):
>>>
>>>"
>>>The H.261-specific control packets differ from normal RTCP packets in
>>>   that they are not transmitted to the normal RTCP destination
>>>   transport address for the RTP session (which is often a multicast
>>>   address).  Instead, these control packets are sent directly via
>>>   unicast from the decoder to the coder.  The destination port for
>>>   these control packets is the same port that the coder uses as a
>>>   source port for transmitting RTP (data) packets.  Therefore, these
>>>   packets may be considered "reverse" control packets.
>>>
>>>   As a consequence, these control packets may only be used when no
>RTP
>>>   mixers or translators intervene in the path from the coder to the
>>>   decoder.  If such intermediate systems do intervene, the address of
>>>   the coder would no longer be present as the network-level source
>>>   address in packets received by the decoder, and in fact, it might
>>not
>>>   be possible for the decoder to send packets directly to the coder.
>>>"
>>
>>The proposal is to use the same FIR packet format as in RFC 2032, but
>to
>>send the request to the standard RTCP port, using the mechanisms from
>>draft-ietf-avt-rtcp-feedback-03.txt to ensure timely feedback. Would 
>>that help?
>>
>>Colin
>
>_______________________________________________
>mmusic mailing list
>mmusic <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 1 comment |
headers
Joerg Ott | 5 Aug 2002 22:20
Picon
Picon

Re: video media control draft

> 
> That would seem to be something for the signalling protocol, since it
> changes the media format. It's not clear to me that this information
> can cleanly be siganlled in SDP though, it may be better suited to an
> SDPng expression?

That's the idea.  And as discussed at the last IETF, we start looking
into a video profile right now.  Depending on the video conferencing
requirements, you may need a few (trivial) parameters in SDP though.

Joerg

> --> "MONFORT Patrick FTRD/DMI/ISS" writes:
> >Hello,
> >
> >Th draft I mentioned in a previous mail
> >"draft-koskelainen-sdp263-02.txt" deals with SIZE and OPTIONS of video
> >codec. How do you propose the manage them during a call.
> >
> >All thoses things are in the stream itself, but, a Video UA need a way
> >to express them during the initiation of the call and to control them
> >during the call.
> >
> >Thanks,
> >
> >Patrick,
> >
> >
> >-----Original Message-----
> >From: Colin Perkins [mailto:csp <at> isi.edu]
> >Sent: vendredi 26 juillet 2002 19:46
> >To: MONFORT Patrick FTRD/DMI/ISS
> >Cc: mmusic <at> ietf.org
> >Subject: Re: [MMUSIC] video media control draft 
> >
> >
> >I'm not sure we agree on the list of other things are needed. Some form
> >of
> >fast intro request, certainly, but what else? Freeze has been discussed,
> >but that may not be necessary. Are there others?
> >
> >Colin
> >
> >
> >
> >--> "MONFORT Patrick FTRD/DMI/ISS" writes:
> >>Yes, that would help.
> >>
> >>As other things are needed, would it be possible to have/imagine an
> >>attribute in the SDP (associated to media or the session) that can
> >>manage all the "control" aspect of media. UA could listen on this
> >>"control" port to receive command from other(s) party(ies).
> >>
> >>Or else, if we don't want to manage a new port, I think we will have a
> >>new SIP message that will carry a new SDP with constraints on it (like
> >>to update only attribute of the declared media) ?
> >>
> >>
> >>-----Original Message-----
> >>From: Colin Perkins [mailto:csp <at> isi.edu]
> >>Sent: mercredi 24 juillet 2002 22:38
> >>To: MONFORT Patrick FTRD/DMI/ISS
> >>Cc: Joerg Ott; Orit Levin; mmusic <at> ietf.org
> >>Subject: Re: [MMUSIC] video media control draft 
> >>
> >>
> >>--> "MONFORT Patrick FTRD/DMI/ISS" writes:
> >>...deleted...
> >>>Regarding the control, RFC 2032 (which describes RTCP packet for
> >>>IntraRequest) can't be deployed. The reason is that these RTCP packets
> >>>are not sent to the 'standard' RTCP Port.
> >>>
> >>>Here are the text taken from RFC 2032, that explains this issue
> >>(section
> >>>5.1):
> >>>
> >>>"
> >>>The H.261-specific control packets differ from normal RTCP packets in
> >>>   that they are not transmitted to the normal RTCP destination
> >>>   transport address for the RTP session (which is often a multicast
> >>>   address).  Instead, these control packets are sent directly via
> >>>   unicast from the decoder to the coder.  The destination port for
> >>>   these control packets is the same port that the coder uses as a
> >>>   source port for transmitting RTP (data) packets.  Therefore, these
> >>>   packets may be considered "reverse" control packets.
> >>>
> >>>   As a consequence, these control packets may only be used when no
> >RTP
> >>>   mixers or translators intervene in the path from the coder to the
> >>>   decoder.  If such intermediate systems do intervene, the address of
> >>>   the coder would no longer be present as the network-level source
> >>>   address in packets received by the decoder, and in fact, it might
> >>not
> >>>   be possible for the decoder to send packets directly to the coder.
> >>>"
> >>
> >>The proposal is to use the same FIR packet format as in RFC 2032, but
> >to
> >>send the request to the standard RTCP port, using the mechanisms from
> >>draft-ietf-avt-rtcp-feedback-03.txt to ensure timely feedback. Would 
> >>that help?
> >>
> >>Colin
> >
> >_______________________________________________
> >mmusic mailing list
> >mmusic <at> ietf.org
> >https://www1.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> mmusic <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>
Permalink | Reply | 0 comments |
headers
Even, Roni | 6 Aug 2002 07:59
Picon

RE: video media control draft

Hi Petri,
In my draft draft-even-mmusic-video-media-control-00.txt, I have a
video-resolution attribute that allow to specify the maximum frame rate
supported per resolution. In the meeting this attribute was accepted for
SDP. I could not find the draft mentioned "draft-koskelainen-sdp263-02.txt"
Thanks
Roni Even

> -----Original Message-----
> From: Petri K. Koskelainen [mailto:petkos <at> cs.columbia.edu]
> Sent: Monday, August 05, 2002 6:45 PM
> To: mmusic <at> ietf.org
> Subject: [MMUSIC] video media control draft
> 
> 
> 
> Hi,
> 
> That draft works only for H.263 codec so it is not
> a general solution. Moreover, using SDP a line 
> to express options (or group of options and 
> complex restrictions) is very difficult.
> 
> In the setup phase, you could advertize your
> codec capabilities (in SDP), so it
> is possible to change options during a call
> without further signaling. But I guess
> it makes sense to inform also signaling level
> about the change (since e.g. bandwidth requirement 
> may change considerably if you change options).
> 
> 
> Petri
> 
> -----------------------------
> 
> Hello,
> 
> Th draft I mentioned in a previous mail
> "draft-koskelainen-sdp263-02.txt" deals with SIZE and OPTIONS of video
> codec. How do you propose the manage them during a call.
> 
> All thoses things are in the stream itself, but, a Video UA need a way
> to express them during the initiation of the call and to control them
> during the call.
> 
> Thanks,
> 
> Patrick,
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>
Permalink | Reply | 1 comment |

Gmane