Hi Stephane "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" Since the offered media mode is "sendonly", you don't need to send any Re-INVITE to this effect because peer is not expected to send RTP in your direction.
Further, in case you offer a "sendonly" video stream with port 1342 and wish to open a different port for "sendrecv" mode, then the new port can be specified to the peer in a new offer (in Re-INVITE or UPDATE) along with mode as "sendrecv". On the other side, you may also continue using this port for bi-directional RTP by just changing the media mode of this stream to "sendrecv" in new offer. Regards Rohit Aggarwal Aricent ________________________________ From: Stephane van Hardeveld [mailto:[email protected]] Sent: Monday, February 16, 2009 3:13 PM To: Rohit Aggarwal; [email protected] 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." ________________________________ "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
