headers
Lior Sion | 1 Oct 2002 10:22

B=AS in SDP

Hello,

We have a long argument about the concept of the bandwidth in the SDP (b=as line), and i would like to raise it
before closure of the new SDP draft.
The question is what part of the session's bandwidth is included in this parameter - data only (no headers),
data + rtp headers, or data + rtp + ip headers, rtp + rtcp, etc. 

Although I've seen all arguments in favor of adding the headers and the RTCP to this value, i can't see how
this can be done. Since the client chooses the block size (using blocksize parameter in RTSP SETUP
request), only then i can calculate the number of packets to be sent, and even this it's only an assumption
(in mpeg4 for example, i can't be sure how many packets the server would create for each frame, due to
headers boundaries). Since protocol headers (i.e., UDP) are added to each packets, total bw can not be
guessed beforehand.

Moreover, at SDP stage, streaming server still doesn't know the underlying protocol. It can be TCP, UDP,
etc. and this has major influence on packet sizes and header sizes per packet.

What do you think?

Lior

**************************************************************************************************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or  the 
sender immediately and do not disclose the contents to any one or make copies.

** eSafe scanned this email for viruses, vandals and malicious content **
**************************************************************************************************
(Continue reading)

Permalink | Reply | 2 comments |
headers
emre.aksu | 1 Oct 2002 10:43
Picon

RE: B=AS in SDP

Hi Lior,
The same discussion took place in November 2001, and I attached the e-mails sent to MMUSIC reflector
related to this issue.
I also think that this value should include the <data + packetization + network header overheads>, by
making a reasonable guess on the possible overhead if no other information is available. 
Currently, 3GPP PSS streaming Spec. (TS 26.234) also follows the same definition.

For RTCP bandwidth, currently in IETF AVT group there is an internet draft to include new SDP attributes to
signal RTCP bandwidth. 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-bw-05.txt

BR
Emre

Emre Baris Aksu

Nokia Mobile Phones
Tampere / Finland
e-mail : emre.aksu <at> nokia.com
Mobile : +358 40 743 1972
Fax    : +358 7180 70504

> -----Original Message-----
> From: ext Lior Sion [mailto:lior.sion <at> emblaze.com]
> Sent: 01. October 2002 11:22
> To: Mmusic (E-mail)
> Subject: [MMUSIC] B=AS in SDP
> 
> 
> Hello,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 1 Oct 2002 11:25
Picon
Picon

Re: B=AS in SDP

Hi Lior,

As Emre says we have had discussion on this topic before. The b=AS in 
the case that the media is transported over RTP is the bitrate of 
IP/UDP/RTP headers + payload data, not including RTCP bitrate.

I agree that it might create some unclarities in the case of streaming 
due to unknown transport, etc. There also exist more problems with this 
approach, namely the overhead for IP headers. With two versions of IP it 
gets problematic. I plan to publish a draft next week that investigates 
this problem.

But to be realistic when can't change the definition of "b=AS". What can 
be done is proposing new bandwidth modifiers that give more appropriate 
values. We should also look at how this shall be handled in SDP-NG.

Regards

Magnus Westerlund

Lior Sion wrote:

>Hello,
>
>We have a long argument about the concept of the bandwidth in the SDP (b=as line), and i would like to raise it
before closure of the new SDP draft.
>The question is what part of the session's bandwidth is included in this parameter - data only (no
headers), data + rtp headers, or data + rtp + ip headers, rtp + rtcp, etc. 
>
>Although I've seen all arguments in favor of adding the headers and the RTCP to this value, i can't see how
(Continue reading)

Permalink | Reply | 1 comment |
headers
Medhavi Bhatia | 1 Oct 2002 16:53

suggestion for new parameter

This is related to: draft-sen-sipping-intrarealm-stun-00.txt.
 
I wanted to propose a change in the mechanism, by introducing
new sdp parameters.
 
The basic aim is to allow media to flow directly between two endpoints
which are in the same realm/domain, where the call goes (or is transferred)
through an externam proxy/B2BUA etc.
 
Whovever is capable of doing nat/stun/other mechanism (client/proxy/B2BUA),
inserts an extra line, m0=<base ip address> <base port> <domain signature>,
where the base ip
address and port represent the original ip/port in the c and m lines,
which are changed for nat purposes. This line can be replaced/deleted
by by another proxy in the chain, who desires that media MUST be routed
through it (in other words, it has control/policy).
 
When an offer containing this SDP reaches the final proxy (to which the
gateway/endpoint is registered), it determines using m0, that the src
media is originaing in the same domain as the final destination. It
removes the old m and c lines, and introduces new lines based on the contents
of the m0 line. This procedure can be done at the final destination, if it supports
the m0 parameter.
 
In other words, the procedure can be both supported on either the proxy/B2BUA or the
endpoint itself. The final endpoint either sees the original m/c line (which are in
its domain) or is able to figure that out if the original m0 line was present.
 
Any comments ?
 
-Medhavi.
Permalink | Reply | 0 comments |
headers
Sanjoy Sen | 3 Oct 2002 17:45

RE: suggestion for new parameter

Medhavi,
 
We did think about a solution to this problem based on signaling alone, but declared that there're too many unknown variables. Firstly, you would need to provision each UA or Proxy with this "domain signature", its unknown how would you compute this domain signature and, lastly, two users in the same domain may not be directly connected (I'm not saying that domain signature is equivalent to a domain, but somehow two users with the same domain signature necessarily implies that there must be a direct connectivity). So we concluded that the best way to figure this out (direct connectivity) is to try directly, i.e. by pinging the other end point at the address/port at which it likes to receive media. And, since there'll be retransmission involved, we would like to allow the call setup progress independently. Also, a mechansim using STUN (and only STUN) would allow other session protocols make use of this mechanism. As Cullen pointed out in a separate SIPPING thread, this may not be STUN per se, but a kind of STUN PING based on STUN (since it would use many of the same STUN parameters & properties).
 
Thanks,
Sanjoy
 
-----Original Message-----
From: Medhavi Bhatia [mailto:mbhatia <at> nextone.com]
Sent: Tuesday, October 01, 2002 9:54 AM
To: mmusic <at> ietf.org
Subject: [MMUSIC] suggestion for new parameter

This is related to: draft-sen-sipping-intrarealm-stun-00.txt.
 
I wanted to propose a change in the mechanism, by introducing
new sdp parameters.
 
The basic aim is to allow media to flow directly between two endpoints
which are in the same realm/domain, where the call goes (or is transferred)
through an externam proxy/B2BUA etc.
 
Whovever is capable of doing nat/stun/other mechanism (client/proxy/B2BUA),
inserts an extra line, m0=<base ip address> <base port> <domain signature>,
where the base ip
address and port represent the original ip/port in the c and m lines,
which are changed for nat purposes. This line can be replaced/deleted
by by another proxy in the chain, who desires that media MUST be routed
through it (in other words, it has control/policy).
 
When an offer containing this SDP reaches the final proxy (to which the
gateway/endpoint is registered), it determines using m0, that the src
media is originaing in the same domain as the final destination. It
removes the old m and c lines, and introduces new lines based on the contents
of the m0 line. This procedure can be done at the final destination, if it supports
the m0 parameter.
 
In other words, the procedure can be both supported on either the proxy/B2BUA or the
endpoint itself. The final endpoint either sees the original m/c line (which are in
its domain) or is able to figure that out if the original m0 line was present.
 
Any comments ?
 
-Medhavi.
Permalink | Reply | 1 comment |
headers
Medhavi Bhatia | 3 Oct 2002 18:02

Re: suggestion for new parameter

Sanjoy,
 
Some more provisioning is definitely needed. Agreed. But the current way also assumes
endpoints are allowed to make that decision. What if two endpoints which are
directly connected are not allowed to talk directly ? This are realistic scenarios,
where policy is often decided at the service provider level. Moreover putting an additional
parameter in SDP will not be signaling (its basically a kind of history, and whoever
wipes out the history can take control of the media. So an intermediate proxy/B2BUA which
decided to route the media can just replace/delete that line.
 
I like the generality of the STUN/ping based idea, but I think the mechanism should handle
the additional requirements. What do you think ?
 
-Medhavi.
 
----- Original Message -----
From: Sanjoy Sen
Sent: Thursday, October 03, 2002 11:45 AM
Subject: RE: [MMUSIC] suggestion for new parameter

Medhavi,
 
We did think about a solution to this problem based on signaling alone, but declared that there're too many unknown variables. Firstly, you would need to provision each UA or Proxy with this "domain signature", its unknown how would you compute this domain signature and, lastly, two users in the same domain may not be directly connected (I'm not saying that domain signature is equivalent to a domain, but somehow two users with the same domain signature necessarily implies that there must be a direct connectivity). So we concluded that the best way to figure this out (direct connectivity) is to try directly, i.e. by pinging the other end point at the address/port at which it likes to receive media. And, since there'll be retransmission involved, we would like to allow the call setup progress independently. Also, a mechansim using STUN (and only STUN) would allow other session protocols make use of this mechanism. As Cullen pointed out in a separate SIPPING thread, this may not be STUN per se, but a kind of STUN PING based on STUN (since it would use many of the same STUN parameters & properties).
 
Thanks,
Sanjoy
 
-----Original Message-----
From: Medhavi Bhatia [mailto:mbhatia <at> nextone.com]
Sent: Tuesday, October 01, 2002 9:54 AM
To: mmusic <at> ietf.org
Subject: [MMUSIC] suggestion for new parameter

This is related to: draft-sen-sipping-intrarealm-stun-00.txt.
 
I wanted to propose a change in the mechanism, by introducing
new sdp parameters.
 
The basic aim is to allow media to flow directly between two endpoints
which are in the same realm/domain, where the call goes (or is transferred)
through an externam proxy/B2BUA etc.
 
Whovever is capable of doing nat/stun/other mechanism (client/proxy/B2BUA),
inserts an extra line, m0=<base ip address> <base port> <domain signature>,
where the base ip
address and port represent the original ip/port in the c and m lines,
which are changed for nat purposes. This line can be replaced/deleted
by by another proxy in the chain, who desires that media MUST be routed
through it (in other words, it has control/policy).
 
When an offer containing this SDP reaches the final proxy (to which the
gateway/endpoint is registered), it determines using m0, that the src
media is originaing in the same domain as the final destination. It
removes the old m and c lines, and introduces new lines based on the contents
of the m0 line. This procedure can be done at the final destination, if it supports
the m0 parameter.
 
In other words, the procedure can be both supported on either the proxy/B2BUA or the
endpoint itself. The final endpoint either sees the original m/c line (which are in
its domain) or is able to figure that out if the original m0 line was present.
 
Any comments ?
 
-Medhavi.
Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 7 Oct 2002 13:22
Picon
Picon

Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt

Hi all,

I have submitted a draft that discuss and tries to address the problem 
with having IP and transport level as a part of the SDP bandwidth 
modifiers. Specifically it looks at the b=AS:<bw-value>. The problems is 
several, but one of the major is a result of having two IP versions 
deployed and having translation between the two. Also header compression 
and future transport protocols (DCCP) creates problems.

So any person working with protocols using SDP (SIP, SAP, RTSP) or 
working with SDP and SDP-NG should look at this draft.

Until it becomes available in the IETF directories it can be fetched 
from here:
<http://standards.ericsson.net/westerlund/draft-westerlund-mmusic-sdp-bwparam-00.txt 
 >

Discussion is encouraged and any comments should be directed to the 
MMUSIC mailing list. SO PLEASE remove the other lists when replying.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> era.ericsson.se
Permalink | Reply | 0 comments |
headers
Tom Marshall | 7 Oct 2002 18:58
Picon
Favicon

Re: Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt

I like the TIAS solution.  I think it's much more reasonable to calculate
only the application bandwidth than try to guess how many bits are in the
headers in lower layers.

On Mon, Oct 07, 2002 at 01:22:32PM +0200, Magnus Westerlund wrote:
> Hi all,
> 
> I have submitted a draft that discuss and tries to address the problem 
> with having IP and transport level as a part of the SDP bandwidth 
> modifiers. Specifically it looks at the b=AS:<bw-value>. The problems is 
> several, but one of the major is a result of having two IP versions 
> deployed and having translation between the two. Also header compression 
> and future transport protocols (DCCP) creates problems.
> 
> So any person working with protocols using SDP (SIP, SAP, RTSP) or 
> working with SDP and SDP-NG should look at this draft.
> 
> Until it becomes available in the IETF directories it can be fetched 
> from here:
> <http://standards.ericsson.net/westerlund/draft-westerlund-mmusic-sdp-bwparam-00.txt 
> >
> 
> Discussion is encouraged and any comments should be directed to the 
> MMUSIC mailing list. SO PLEASE remove the other lists when replying.
> 
> Regards
> 
> 
> Magnus Westerlund 
> 
> Multimedia Technologies, Ericsson Research ERA/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> era.ericsson.se
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

--

-- 
If you make people think they're thinking, they'll love you; but if you
really make them think they'll hate you.
Permalink | Reply | 0 comments |
headers
Lior Sion | 8 Oct 2002 13:42

RE: Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt

Hi,

why not go all the way with this solution and signal only the DATA bw value? As i've noted before, sometimes
there's a case when the server doesn't know in advance the packet rate and/or the size of these - simply
because the server should try and use the client's "blocksize" parameter. Since using this value changes
number of packets AND total bw, the client can use the knowledge of the data bw only in order to request the
correct blocksize.

Also, why not use this opportunity, and use bps instead of KBps?

Lior Sion

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund <at> era.ericsson.se]
Sent: Monday, October 07, 2002 1:23 PM
To: IETF MMUSIC WG
Cc: IETF AVT WG; IETF SIPPING WG
Subject: [MMUSIC] Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt

Hi all,

I have submitted a draft that discuss and tries to address the problem 
with having IP and transport level as a part of the SDP bandwidth 
modifiers. Specifically it looks at the b=AS:<bw-value>. The problems is 
several, but one of the major is a result of having two IP versions 
deployed and having translation between the two. Also header compression 
and future transport protocols (DCCP) creates problems.

So any person working with protocols using SDP (SIP, SAP, RTSP) or 
working with SDP and SDP-NG should look at this draft.

Until it becomes available in the IETF directories it can be fetched 
from here:
<http://standards.ericsson.net/westerlund/draft-westerlund-mmusic-sdp-bwparam-00.txt 
 >

Discussion is encouraged and any comments should be directed to the 
MMUSIC mailing list. SO PLEASE remove the other lists when replying.

Regards

Magnus Westerlund 

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

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

**************************************************************************************************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or  the 
sender immediately and do not disclose the contents to any one or make copies.

** eSafe scanned this email for viruses, vandals and malicious content **
**************************************************************************************************
Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 8 Oct 2002 14:06
Picon
Picon

Re: Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt

Hi,

Yes, we could only count the payload data. I guess that makes it 
possible to address the cases when somebody are not using RTP at all, 
but rather a stream based transport. One must however be careful in 
different application to not think that a payload data rate is enough. 
In all RTP transported cases it will be required to  know the packet 
rate to be able to calculate the correct total BW. But I agree that 
there are cases when the packet rate can influenced by other protocols 
like the RTSP header blocksize. The total solution for this should also 
be considered, to see that a server can tell the client the result of 
its choices.

Regarding the kbps. I was only following the syntax rules that applies 
for a bandwidth modifier for the b= line. The SDP specification says 
that they shall be in kbps. However maybe we should discuss to change 
this. Already the RR and RS modifiers from draft-ietf-avr-rtcp-bw-05.txt 
uses bps. So shall all future modifiers use bps?

Regards

Magnus

Lior Sion wrote:

>Hi,
>
>why not go all the way with this solution and signal only the DATA bw value? As i've noted before, sometimes
there's a case when the server doesn't know in advance the packet rate and/or the size of these - simply
because the server should try and use the client's "blocksize" parameter. Since using this value changes
number of packets AND total bw, the client can use the knowledge of the data bw only in order to request the
correct blocksize.
>
>Also, why not use this opportunity, and use bps instead of KBps?
>
>Lior Sion
>
>-----Original Message-----
>From: Magnus Westerlund [mailto:magnus.westerlund <at> era.ericsson.se]
>Sent: Monday, October 07, 2002 1:23 PM
>To: IETF MMUSIC WG
>Cc: IETF AVT WG; IETF SIPPING WG
>Subject: [MMUSIC] Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt
>
>
>Hi all,
>
>I have submitted a draft that discuss and tries to address the problem 
>with having IP and transport level as a part of the SDP bandwidth 
>modifiers. Specifically it looks at the b=AS:<bw-value>. The problems is 
>several, but one of the major is a result of having two IP versions 
>deployed and having translation between the two. Also header compression 
>and future transport protocols (DCCP) creates problems.
>
>So any person working with protocols using SDP (SIP, SAP, RTSP) or 
>working with SDP and SDP-NG should look at this draft.
>
>Until it becomes available in the IETF directories it can be fetched 
>from here:
><http://standards.ericsson.net/westerlund/draft-westerlund-mmusic-sdp-bwparam-00.txt 
> >
>
>Discussion is encouraged and any comments should be directed to the 
>MMUSIC mailing list. SO PLEASE remove the other lists when replying.
>
>Regards
>
>
>Magnus Westerlund 
>
>Multimedia Technologies, Ericsson Research ERA/TVA/A
>----------------------------------------------------------------------
>Ericsson AB                | Phone +46 8 4048287
>Torshamsgatan 23           | Fax   +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> era.ericsson.se
>
>
>_______________________________________________
>mmusic mailing list
>mmusic <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/mmusic
>
>**************************************************************************************************
>The contents of this email and any attachments are confidential.
>It is intended for the named recipient(s) only.
>If you have received this email in error please notify the system manager or  the 
>sender immediately and do not disclose the contents to any one or make copies.
>
>** eSafe scanned this email for viruses, vandals and malicious content **
>**************************************************************************************************
>

--

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> era.ericsson.se
Permalink | Reply | 0 comments |

Gmane