Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #117 - 10 msgs

From: [email-masked]
Date: Thu, 05 Feb 2004 08:45:08 -0800

This is an automatic digest of bugs submitted and changed on the RTSP bug tracker.  To see a list of bugs, visit:

http://sf.net/projects/rtspspec

When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest"

Today's Topics:

   1. [ rtspspec-Bugs-678107 ] Change of Proxy-Require header (SourceForge.net)
   2. [ rtspspec-Feature Requests-707252 ] Update the RTSP URI schemes to support IRI (SourceForge.net)
   3. [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules (SourceForge.net)
   4. [ rtspspec-Bugs-742328 ] How to handle PLAY request when at the end of a media clip (SourceForge.net)
   5. [ rtspspec-Bugs-742348 ] Usage of implicit REDIRECT. (SourceForge.net)
   6. [ rtspspec-Bugs-755472 ] Restricted use of Range header time parameter (SourceForge.net)
   7. [ rtspspec-Bugs-770522 ] Request to response time is not limited. (SourceForge.net)
   8. [ rtspspec-Bugs-771638 ] a=range in SDP to indicate live media (SourceForge.net)
   9. [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session (SourceForge.net)
  10. [ rtspspec-Bugs-770522 ] Request to response time is not limited. (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 04 Feb 2004 08:12:14 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-678107 ] Change of Proxy-Require header

Bugs item #678107, was opened at 2003-01-31 13:43
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=678107&group_id=23194

Category: General
Group: Resolved - Added to text
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Change of Proxy-Require header

Initial Comment:
Current text: Says that proxy-require applies to both
proxy and server.

New Proposal: The feature tags in a "Proxy-require"
header will only apply to the proxies, and not the
server. For feature that the server must support the
"Require" header shall be used. If required feature
support from both proxy and server both "Proxy-Require"
and "Require" must be used.

Pro:
- Align with SIP's usage of header
- Makes it possible to create features tags for proxy
only functionality. Otherwise all servers will be
mandated to also know about proxy only features.

Cons: 
- Backwards compatibility. (Actually this does not
matter much as: A old server implementing the old way
would also not work with any new feature tags for
proxies. So it will block operation independent of
changed semantics or not.)

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-04 17:12

Message:
Logged In: YES 
user_id=302620

No comments received, text incorperated. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 13:54

Message:
Logged In: YES 
user_id=302620

The necessary text changes have been written in and will
become available in version 05 of the draft. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-07-10 11:42

Message:
Logged In: YES 
user_id=302620

Whas resolved at the telecon january 22 2003. 
Resolution: Proxy-require shall only apply to proxies not
servers. 

Needs to be changed in the specification. Should also
clarify that a feature tag can be of type, proxy, server or
both. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=678107&group_id=23194

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 04 Feb 2004 08:14:04 -0800
Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-707252 ] Update the RTSP URI schemes to support IRI

Feature Requests item #707252, was opened at 2003-03-21 01:45
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377747&aid=707252&group_id=23194

>Category: None
>Group: None
Status: Open
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Nobody/Anonymous (nobody)
>Summary: Update the RTSP URI schemes to support IRI

Initial Comment:
The current RTSP schemes has been updated to allow 
for literall IPv6. However the URI scheme should also be 
updated to cover IRI (Internationalized Resource 
Identifiers). I (Magnus W) will try to get more information 
on this from the people having created the IRI. Hopefully 
this is little or no work.

For people to read up on URI scheme considerations 
and other things should look at:
RFC 2717 and 2718. I hade so far not had time to dig up 
any references to the IRI work. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-04 17:13

Message:
Logged In: YES 
user_id=302620

Moving this to feature request as it is an extension. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377747&aid=707252&group_id=23194

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 04 Feb 2004 08:16:55 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules

Bugs item #739845, was opened at 2003-05-19 14:13
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: "a=range" is missing IANA registration and clear rules

Initial Comment:
The "a=range" SDP attribute in appendix C.1.5 of the
specification has some issues.

1. The parameter is not registered with IANA. Write
IANA registration request.

2. The parameter is not clearly defined in regards to
ABNF. Write ABNF definition for attribute don't forget
extension for new format types.

3. Is multiple range specifications allowed?

4. Write normative language on usage regarding session
and media level. 

5. Is multiple instances for the different formats allowed?

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-04 17:16

Message:
Logged In: YES 
user_id=302620

No Comments, text available. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 13:16

Message:
Logged In: YES 
user_id=302620

As discussed in MMUSIC the following definition will be added:

If the "a=range" attribute contains an open ended
range
(fmt=start-) this media or session is of unknown duration
and SHALL be considered as non seekable unless this property
is overriden. 

This has been edited in and will appear in the 05 draft version.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-06-05 12:45

Message:
Logged In: YES 
user_id=302620

Changes are now editied in. See IANA.tex and SDP.tex

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-06-05 11:31

Message:
Logged In: YES 
user_id=302620

Has been discussed at telecon

1. Write IANA registration
2. Write ABNF 
3. No
4. Yes, will be included.
5. No

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&group_id=23194

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 04 Feb 2004 08:24:36 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-742328 ] How to handle PLAY request when at the end of a media clip

Bugs item #742328, was opened at 2003-05-23 15:44
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742328&group_id=23194

Category: None
Group: Fix - Discussed/Resolved
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: How to handle PLAY request when at the end of a media clip

Initial Comment:
This is a problem that has surfaced in interoperability
test. It shouldn't surface in a correct implemented
client talking to a correct server. However how should
the server handle it if still happens.

The scenario is:
The server is playing a stored media clip to the
client. The client has a certain amount of buffer
space. The client hits PAUSE. However when the PAUSE
request reaches the server the server has played all
media for the clip. The server respond to the PAUSE
request with a Range header containing the pause point.
The problem arise when the client likes to resume the
playout of  the media to the end. The client has all
the rest of the media already in its buffer and this
should be totally local operation.

There are three reasons I see why the client may not
know that this is a local operation:
1. The client has not been informed about the duration
of the media. Therefore it can use the pause point in
the response to determine that the server is at the end
of the media clip.
2. The server has not included the pause point in the
PAUSE response, may happen for RFC 2326 servers. This
is a MUST in the new specification.
3. The client does not check the duration against the
given pause point. This the client SHOULD do to prevent
this from happening.

Any of the three above would result in that the client
sends a PLAY request to resume playing (no range
header) at the pause point. However the server is
already at the of the media clip. So the big question
is how the server handles this PLAY request?

I can see two ways of resolving it and would like some
input on which is the recommended one.

A. The server sends a 200 OK on the request to
continue. The RTP-Info is for the next packet which
will not be sent as result of this PLAY request. The
Range header response indicate that the server will
play from the given end of the clip to the end of the
clip. Then no RTP packets are sent.

B. The server sends a 457 (Invalid Range) including in
the response the range header for the pause point.

In my opinion the best alternative is B. This clearly
indicate to the client that no media will be delivered.
Also it is in line with the semantics that a PLAY
request is only performed when the range is within the
media clip.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-04 17:24

Message:
Logged In: YES 
user_id=302620

No comments, closing issue.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 13:38

Message:
Logged In: YES 
user_id=302620

The resolution B has been added to the text in the PLAY
method. Will become available from draft version 05. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-06-13 16:08

Message:
Logged In: YES 
user_id=302620

At the telecon 28th of May 2003 it was the conclusion to use
resoultion b. Needs to be written up. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742328&group_id=23194

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 05 Feb 2004 02:00:10 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-742348 ] Usage of implicit REDIRECT.

Bugs item #742348, was opened at 2003-05-23 16:21
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742348&group_id=23194

>Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Aravind Narasimhan (arvy_n)
Summary: Usage of implicit REDIRECT. 

Initial Comment:
The RTSP specification provides two explict methods of
redirection, the REDIRECT method and the 3XX response
codes. 

Further it is possible to do implict redirection in the
media description. This is done by affecting the RTSP
control URLs present for the different media. By giving
the client a description that either contains absolute
URLs or URLs that resolve to another host the
redirection takes place.

The redirection changes the URL in the redirection.
This can be done in three ways:
Changing the absolute URLs in the description. 
Using Content-Location header to set the Base URL to
point to another host.
Using Content-Base header to set the base URL to point
to another host. 

The two last may require changes of any relative URLs
in the description also.

Of these methods the usage of Content-Location may be
the one that have the most correct semantics. This of
course requires that the host being redirected to has
the complet session including description. As the
Content-Location header tells the client that the given
location is an possible resolution for this exact
description. 

The Client Implementation requirement to get this
functionality is that it after resolving the URLs check
them against the current server address. If different
it needs to get a new connection to the new server.
This seems fairly simple. 

Also see mail to MMUSIC mailing list from Philippe Gentric

The question is if this behavior shall be considered a
valid one or not. The outcome of the discussion should
be written in as a clarification to the text of the
RTSP specification. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 17:54

Message:
Logged In: YES 
user_id=302620

From the 57th IETF meeting 16th of July 2003:

Issue: How to handle implicit redirection through session
description protocol.

Discussion: Seems to be desired functionality to have an
optimized way for saving a RTT when you perform load
balance. There where also the issue that if a server would
give a content-base or other base URL. A client should not
reconnect unless explicitly redirected. This may result in
different behaviour depending if the client are behind a
proxy or not. First it was proposed that a new 200 code can
be used to indicate that you get the SDP but are redirected.
However this seem to have backwards problem. To optimize
this in a efficient way you can use a new 350 code to
indicate redirection but the client does receive a SDP. This
way a old client will do the redirect as it interprets is as
3xx code, while a new client can avoid wasting a extra
describe. There are also a need to clarify that a server
should not change the host address of the control in regards
to the describe URI.

Resolution: Create a 350 code for this plus clarify the
SHOULD NOT change the host address. Seems reasonable to put
into the core specification. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742348&group_id=23194

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 05 Feb 2004 06:57:47 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-755472 ] Restricted use of Range header time parameter

Bugs item #755472, was opened at 2003-06-16 20:37
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=755472&group_id=23194

Category: None
Group: Fix - Discussed/Resolved
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Restricted use of Range header time parameter

Initial Comment:
The Range header's time parameter has been deprecated
from use in PLAY and PAUSE method. The only method
still using the time parameter is REDIRECT. 

The decision to stop using time= for PAUSE and PLAY was
discussed at the 56th IETF and at the April 16th telecon. 

Reasons is that they create hard synchronization
problems and possilbe failure modes that does not give
the client any error codes. There was also no need seen
for the functionality. 

The change has been edited in and will be published
from version 4 of the draft. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-05 15:57

Message:
Logged In: YES 
user_id=302620

No comments given, all edited in, closing issue. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 13:16

Message:
Logged In: YES 
user_id=302620

Sorry, text went on wrong item. Please disregard.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 13:07

Message:
Logged In: YES 
user_id=302620

As discussed in MMUSIC the following definition will be added:

If the "a=range" attribute contains an open ended range
(fmt=start-) this media or session is of unknown duration
and SHALL be considered as non seekable unless this property
is overriden. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=755472&group_id=23194

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 05 Feb 2004 06:59:46 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-770522 ] Request to response time is not limited.

Bugs item #770522, was opened at 2003-07-13 16:00
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=770522&group_id=23194

>Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: Request to response time is not limited.

Initial Comment:
The time a server is expected to respond to a request
in is not defined. This may create interoperability
issues that a certain client timesout while another
will wait. We should define some time limits for this.
Then a server can know that a request needs to be
adressed in a certain time. If the server processing
takes to long time the server can send a 1xx code to
indicate the request as being under processing. 

The SIP spec can provide hints on how to solve this.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-05 15:59

Message:
Logged In: YES 
user_id=302620

This was further discussed in Minneapolis. Sean has provided
text, which was further discussed on the mailing list.
Awaiting updated text for integration into specification. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 17:56

Message:
Logged In: YES 
user_id=302620

From the 57th IETF meeting 16th of July 2003:

Issue:  Request to Response time-out. The time a request
takes until any response is received is not bound. Look at
SIP solution?

Discussion: The time for a request to be processed is not
defined. IF a server is taking long time to process a
request it could send a 1xx response to indicate what it is
doing. There may be soon need for this, especially if one
uses STUN to validate connectivity. Concerns to backwards
compatibility that a client will not expect a 1xx response
even if this has been defined in RFC 2326. A couple to 10
seconds seem to be a reasonable time for a time-out. Does
not seem appropriate to use without a feature tag. However a
clarification on the issue is probably not a bad thing.
There where also some concerns about the CSeq.

Resolution: Not resolved, Aravind to write to the list. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=770522&group_id=23194

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 05 Feb 2004 07:01:27 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-771638 ] a=range in SDP to indicate live media

Bugs item #771638, was opened at 2003-07-15 16:46
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=771638&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: a=range in SDP to indicate live media

Initial Comment:
Today there is some confusion on how a client should
know that media is live. To be able to indicate this in
SDP the following is proposed:

Use a=range with any timeformet but in open ended style
will indicate that the media is live, e.g.
a=range:npt=0- or a=range:npt=now-. This makes it
possible to use also for sessions using SMTPE or UTC
times. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-05 16:01

Message:
Logged In: YES 
user_id=302620

Added in, no comments, closing issue.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 17:15

Message:
Logged In: YES 
user_id=302620

This has been added into the SDP appendix. Awaiting review.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=771638&group_id=23194

--__--__--

Message: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 05 Feb 2004 07:06:20 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session

Bugs item #772330, was opened at 2003-07-16 16:09
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=772330&group_id=23194

>Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Clarify that RTCP shall be sent during whole session

Initial Comment:
Appendix B should be clarified to point out that RTCP
is expected to be sent from succesful response of SETUP
until TEARDOWN. During PAUSE the server and client
should both continue to send RTCP as normal. 

Motivations to this behavior is:
- to avoid timing out SSRC, 
- ensure detection of packet loss at the end of stream.
- ensure that RTCP syncrhonization can work (necessary
for multiple SSRC). 
- Ensure that RTP stream work prior to PLAY if there is
some delay between them. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-05 16:06

Message:
Logged In: YES 
user_id=302620

No comments given, closing issue. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 17:42

Message:
Logged In: YES 
user_id=302620

A clarification about this has been written into appendix B. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-07-16 16:12

Message:
Logged In: YES 
user_id=302620

At the same time it should be made clear the RTCP BYE is
sent when the session is terminated, i.e. at the time of
teardown.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=772330&group_id=23194

--__--__--

Message: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 05 Feb 2004 08:44:36 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-770522 ] Request to response time is not limited.

Bugs item #770522, was opened at 2003-07-13 16:00
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=770522&group_id=23194

Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Request to response time is not limited.

Initial Comment:
The time a server is expected to respond to a request
in is not defined. This may create interoperability
issues that a certain client timesout while another
will wait. We should define some time limits for this.
Then a server can know that a request needs to be
adressed in a certain time. If the server processing
takes to long time the server can send a 1xx code to
indicate the request as being under processing. 

The SIP spec can provide hints on how to solve this.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-05 17:44

Message:
Logged In: YES 
user_id=302620

Text has been added in connections chapter. Please review. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-05 15:59

Message:
Logged In: YES 
user_id=302620

This was further discussed in Minneapolis. Sean has provided
text, which was further discussed on the mailing list.
Awaiting updated text for integration into specification. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 17:56

Message:
Logged In: YES 
user_id=302620

From the 57th IETF meeting 16th of July 2003:

Issue:  Request to Response time-out. The time a request
takes until any response is received is not bound. Look at
SIP solution?

Discussion: The time for a request to be processed is not
defined. IF a server is taking long time to process a
request it could send a 1xx response to indicate what it is
doing. There may be soon need for this, especially if one
uses STUN to validate connectivity. Concerns to backwards
compatibility that a client will not expect a 1xx response
even if this has been defined in RFC 2326. A couple to 10
seconds seem to be a reasonable time for a time-out. Does
not seem appropriate to use without a feature tag. However a
clarification on the issue is probably not a bad thing.
There where also some concerns about the CSeq.

Resolution: Not resolved, Aravind to write to the list. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=770522&group_id=23194

End of Rtspspec-bugs Digest

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic