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 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of stephane Sent: Monday, February 16, 2009 1:04 PM To: [email protected] Subject: [Sip-implementors] Problem with SDP negotiation wrt a-synchronousoffer Not sure if this is the right location to post this question; if not, my apologies to you all. I have a problem with interpreting RFC 3264 and rfc 4566. Specifically, what is the meaning of recvonly and sendonly in the SDP of an offer. When I send an INVITE with a SDP signalling two sets of mediastreams, one set indicating my encoding capabilities, the other indicating my decoding capabilities, I would generate an SDP like the following (specific stream attributes omitted for readability): SDP: v=0 o=- 10668468788867098624 10668468788867098624 IN IP4 10.0.0.58 s=VirCom-session c=IN IP4 10.0.0.58 t=0 0 m=video 1338 RTP/AVP 34 32 a=recvonly a=rtpmap:32 MPV/90000 a=rtpmap:34 H263/90000 m=audio 1340 RTP/AVP 14 0 96 a=recvonly a=rtpmap:14 MPA/90000 a=rtpmap:0 PCMU/8000 a=rtpmap:96 G726-32/8000 m=video 1342 RTP/AVP 32 34 33 a=sendonly a=rtpmap:32 MPV/90000 a=rtpmap:34 H263/90000 m=audio 1344 RTP/AVP 14 0 a=sendonly a=rtpmap:14 MPA/90000 a=rtpmap:0 PCMU/8000 What I hope to achieve is telling my counterpart that I wish to recieve MPEG2 video or H.263 video on port 1338, and MPEG audio or mu-law audio on port 1340, and will sent video and audio on port 1342 and 1344 respectively. The IP phone I tested this with (a Grandstream GXV 3000) responded with the following (again, stream attributes omitted): v=0 o=system 8000 8000 IN IP4 10.0.0.150 s=SIP Call c=IN IP4 10.0.0.150 t=0 0 m=audio 5004 RTP/AVP 0 a=sendrecv a=rtpmap:0 PCMU/8000 m=video 5006 RTP/AVP 34 a=sendrecv a=rtpmap:34 H263/90000 To me, this seemed to indicate it wished to sent audio from port 5004, and also recieve it there, and to receive and sent video on port 5006. I assumed it would sent audio and video to my ports 1338 and 1340, but instead it uses port 1342 and 1344! The question is, how should I interpret recvonly and sendonly. Do these attributes indicate MY side of the dialog, or do they indicate the connection information I expect from my counterpart? Or is this dependent on which RFC is followed (ie RFC 4566 or rfc3264), and is it possible to signal this difference in some kind of version string in the INVITE or OK messages? With regards, Stephane van Hardeveld _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors 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
