Hi Shamik
I slightly differ from what you've mentioned.
----------------------------
m=video 1342 RTP/AVP 32 34 33
a=sendonly
should be interpreted as:
"Callee, I will use local port 1342 to receive RTCP report about the video
I sent you,in this stream."
----------------------------
IMO, Callee will use local port 1343 to receive RTCP and not 1342.
As you have already specified earlier, RFC 3264 (Page 6) explains this:
For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated.
RFC 2327 (Page 20) mentions the description for port in m-line.
o The second sub-field is the transport port to which the media
stream will be sent. The meaning of the transport port depends on
the network being used as specified in the relevant "c" field and
on the transport protocol defined in the third sub-field. Other
ports used by the media application (such as the RTCP port, see
[2]) should be derived algorithmically from the base media port.
Note: For transports based on UDP, the value should be in the range
1024 to 65535 inclusive. For RTP compliance it should be an even
number.
For applications where hierarchically encoded streams are being
sent to a unicast address, it may be necessary to specify multiple
transport ports. This is done using a similar notation to that
used for IP multicast addresses in the "c=" field:
m=<media> <port>/<number of ports> <transport> <fmt list>
In such a case, the ports used depend on the transport protocol.
For RTP, only the even ports are used for data and the
corresponding one-higher odd port is used for RTCP. For example:
m=video 49170/2 RTP/AVP 31
would specify that ports 49170 and 49171 form one RTP/RTCP pair and
49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below).
Further, RFC 3605 [Real Time Control Protocol (RTCP) attribute in Session
Description Protocol (SDP)] explains the RTCP attribute to specify the RTCP
port used for media stream, when that port is not the next higher (odd) port
number following the RTP port described in the media line.
Based on the above explanation, peer will send RTCP on port 1343 (1342 + 1).
However, if the Caller wishes to receive RTCP on a different port (say 1351),
it can be specified as follows:
----------------------------
m=video 1342 RTP/AVP 32 34 33
a=sendonly
a=rtcp: 1351
----------------------------
Regards
Rohit Aggarwal
Aricent
________________________________
From: [email protected] [mailto:[email protected]]
Sent: Monday, February 16, 2009 4:20 PM
To: [email protected]
Cc: [email protected]; Rohit Aggarwal
Subject: RE: [Sip-implementors] Problem with SDP negotiation
wrta-synchronousoffer
Hi Stephane,
your first two interpretaions are correct,
but regarding the remaining they will be more like as follows:
m=video 1342 RTP/AVP 32 34 33
a=sendonly
should be interpreted as:
"Callee, I will use local port 1342 to receive RTCP report about the video
I sent you,in this stream."
m=audio 1344 RTP/AVP 14 0
a=sendonly
should be interpreted as:
"Callee, I will use local port 1342 to receive RTCP information about the
audio I sent you,in this stream."
The ports 1342 and 1344 on sendonly streams does not indicate that we will use
them to recieve media on them.
Here I could like to make a point,In the RFC I have not found anything that
says that in this port I will receive RTCP reports about this stream only,so
this part may need a bit more clarification.If there are many streams,then I
think the offerer cannot distinguish between which RTCP report it is receiving
in which port,unless the answerer takes care to deliver them responsibly.
The response SDP:
"m=audio 5004 RTP/AVP 0
a=sendrecv"
should then be interpreted as:
"Caller, I will receive audio type 0 in local port 5004 . I will use port
5005 for RTCP communication"
m=video 5006 RTP/AVP 34
a=sendrecv
should then be interpreted as:
"Caller, I will receive video type 34 from local port 5006. I will use port
5007 for RTCP communication"
The RFC3264 clearly states that the port numbers in the sendonly and sendrecv
streams does not indicate anything about the sending port.
"The IP address and port present in the offer indicate nothing about the source
IP
address and source port of RTP and RTCP packets that will be sent by
the offerer."-RFC3264
.
reagrding your last question I could like to quote
"A port number of zero in the offer indicates that the
stream is offered but MUST NOT be used. "-RFC3264
But there are certain points that you must remember
"A port number of zero in the offer indicates that the
stream is offered but MUST NOT be used. This has no useful semantics
in an initial offer, but is allowed for reasons of completeness,
since the answer can contain a zero port indicating a rejected stream
(Section 6). Furthermore, existing streams can be terminated by
setting the port to zero (Section 8). In general, a port number of
zero indicates that the media stream is not wanted."-RFC3264
Thanks and regards,
Shamik Saha
Project Engineer
Voice Protocols
Cell : +91-9886704155
________________________________
From: Stephane van Hardeveld [mailto:[email protected]]
Sent: Monday, February 16, 2009 3:13 PM
To: Rohit Aggarwal; Shamik Saha (WT01 - Telecom Equipment)
Cc: [email protected]
Subject: Re: [Sip-implementors] Problem with SDP negotiation
wrta-synchronousoffer
To sum it all up:
"m=video 1338 RTP/AVP 34 32
a=recvonly"
should be interpreted as:
"Callee, sent your video of type 34 or 32 to my local port 1338, and let us
use my local port 1339 for RTCP communication"
"m=audio 1340 RTP/AVP 14 0 96
a=recvonly"
should be interpreted as:
"Callee, sent your audio of type 14, 0 or (dyn.) 96 to my local port 1340,
and let us use my local port 1341 for RTCP communication"
m=video 1342 RTP/AVP 32 34 33
a=sendonly
should be interpreted as:
"Callee, I will use local port 1342 to sent video from, so let us use my
local port 1343 for RTCP communication"
m=audio 1344 RTP/AVP 14 0
a=sendonly
should be interpreted as:
"Callee, I will use local port 1342 to sent video from, so let us use my
local port 1343 for RTCP communication"
The response SDP:
"m=audio 5004 RTP/AVP 0
a=sendrecv"
should then be interpreted as:
"Caller, I will sent audio type 0 from local port 5004, and expect to
recieve it here as well. I will use port 5005 for RTCP communication"
m=video 5006 RTP/AVP 34
a=sendrecv
should then be interpreted as:
"Caller, I will sent video type 34 from local port 5006, and expect to
recieve it here as well. I will use port 5007 for RTCP communication"
This results in the following UDP tupels:
Caller Callee
Video out: port 1342 ==> port 5006 (video in)
Video rtcp: port 1343 <==> port 5007
Audio out: port 1344 ==> port 5004 (audio in)
Audio rtcp: port 1345 <==> port 5005
Video in: port 1338 <== port 5006 (video out)
Video rtcp: port 1339 <== port 5007 (this may cause problems?)
Audio in: port 1340 <== port 5004 (audio out)
Video rtcp: port 1341 <== port 5005 (this may cause problems?)
Or should we use a separate stream attribute (a=rtcp:) to indicate one port for
rtcp communication per media type?
And Rohit, your last statement:
(and perhaps video and audio RTP on 1342 and 1344 respectively).
Do you mean that sendonly may mean sendrecv? Should I sent a re-invite with a
different SDP indicating I definitely do not wish to receive on my sendonly
ports? And how may I indicate that??
With regards,
Stephane van Hardeveld
VirtuosoMedia
----- Original Message -----
From: Rohit Aggarwal<mailto:[email protected]>
To: Stephane van Hardeveld<mailto:[email protected]> ;
[email protected]<mailto:[email protected]>
Cc:
[email protected]<mailto:[email protected]>
Sent: Monday, February 16, 2009 10:24 AM
Subject: RE: [Sip-implementors] Problem with SDP negotiation
wrta-synchronousoffer
Hi
Local SDP contains the port numbers where the entity wishes to receive media.
By default, RTCP is received on port number one higher than the advertised RTP
port.
Refer to the following text in Shamik's mail:
"For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. "
IMO, the SDP in Stephane's mail will be interpreted by the peer entity as
follows:
- Offerer wishes to receive audio RTP on port 1340.
- Offerer wishes to receive video and audio RTCP reports on port
numbers 1343 and 1345 respectively (and perhaps video and audio RTP on 1342 and
1344 respectively).
m=audio 1340 RTP/AVP 14 0 96
a=recvonly
m=video 1342 RTP/AVP 32 34 33
a=sendonly
m=audio 1344 RTP/AVP 14 0
a=sendonly
Regards
Rohit Aggarwal
Aricent
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Stephane
van Hardeveld
Sent: Monday, February 16, 2009 1:56 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [Sip-implementors] Problem with SDP negotiation
wrta-synchronousoffer
Hi Shamik,
So, in short, my interpretation in assuming the ports of the recvonly
statement indicate the ports the offerer/caller (via the INVITE) expects to
receive multimedia data is correct? And the SIP phone implementation we
tested with is not correct in sending this multimedia data to the ports
defined as sendonly?
With regards,
Stephane van Hardeveld
Manager R&D, VirtuosoMedia
----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Monday, February 16, 2009 9:01 AM
Subject: RE: [Sip-implementors] Problem with SDP negotiation wrt
a-synchronousoffer
Hi Stephane,
The port numbers that are given for send only streams are the port
numbers where it will receive the rtcp reports,
In the SDP offer we need not mention the port numbers for a send only
stream,as the far-end need not know about the port number from which we
are transmitting.I am quoting a section of rfc 3264 which tells about
this
For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address
and port present in the offer indicate nothing about the source IP
address and source port of RTP and RTCP packets that will be sent by
the offerer.
So in your scenario,the SDP that you wants to generate tells that you
want to video on 1338,audio on 1340 and receive rtcp reports about the
video you sent, on 1342 and audio you sent, on 1344.
The SDP for the ip phone tells that it will receive audio on 5004 and
vedio on 5006.
Thanks and regards,
Shamik Saha
Project Engineer
Voice Protocols
Cell : +91-9886704155
________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for
the use of the individual to whom it is addressed. It may contain privileged or
confidential information and should not be circulated or used for any purpose
other than for what it is intended. If you have received this message in
error,please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. Aricent accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus."
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for
the use of the individual to whom it is addressed. It may contain privileged or
confidential information and should not be circulated or used for any purpose
other than for what it is intended. If you have received this message in
error,please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. Aricent accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus."
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
