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]
Cc: [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
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
