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

Reply via email to