[SIPForum-discussion] recvonly in sdp

Stephen James sjames_1958 at yahoo.com
Tue Sep 11 17:59:39 UTC 2012


The port of non-zero is not required, but I would include it for 
interoperability.

>From 3264 - this indicates that zero is allowed. But, you might run into 
problems with implementations that do not support it. 

Simply send the same port as in the previous SDP. Interesting, you have 0.0.0.0 
for your IP address and are stating recvonly - which doesn't make a lot of 
sense.
You are receive only to a IP of 0.0.0.0. Perhaps you intend sendonly, if you use 
that then you don't have to zero out your IP address, which is no longer 
recommended.

A port number of zero in the offer indicates that the    stream is offered but 
MUST NOT be used.

 
Stephen James 
sjames_1958 at yahoo.com
 
We are not princes of the earth, we are the descendants of worms, and any 
nobility must be earned.





________________________________
From: Prem chandiran <toprem.m at gmail.com>
To: discussion at sipforum.org
Sent: Tue, September 11, 2012 11:06:09 AM
Subject: [SIPForum-discussion] recvonly in sdp


Hi all,
for putting a caller in call hold we are sending the following sdp.
v=0 
o=46727870367 1338208426 1338208966 IN IP4 10.47.16.5 
s=SCM 
c=IN IP4 0.0.0.0 
t=0 0 
m=audio 37384RTP/AVP 0 
a=ptime:20 
a=rtpmap:0 pcmu/8000 
a=recvonly  

my question is when we send a=recvonly at that time do we need to mention port 
in m attribute as mentioned in the above example or we have to give port as 0 in 
m attribute?. i checked rfc 4566 in section 5.SDP Specification i am able to 
find an example which is similar to the above sdp. but still i am raising this 
concern since i am unable to find any line in the rfc 4566 specifying while 
sending recvonly sdp must have m attribute port as 0 or any valid port number. 
 if any rfc is there plz mention the same . I kindly request you all to help in 
this. 

Thanks,
Prem 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20120911/b6428a95/attachment-0002.html>


More information about the discussion mailing list