I am investigating the use of connection oriented media with sip. I am
trying to follow draft-ietf-mmusic-sdp-comedia-00. This seems to
introduce some new issues for the way SIP uses SDP:
1) For connection oriented media, what does it mean to put the media on
hold, and how do you specify it?
Using a bidirectional connection oriented transport like TCP/IP, in
general there is no way to ensure that data will not be sent to me.
About the best I can do is ensure that the other endpoint knows I don't
want anything sent to me. But I can't do this by sending sdp with
c=0.0.0.0. Seems like the closest I might be able to come is to reinvite
with sdp containing a=recvonly.
2) In general reinvites seem to be a problem with this draft.
Suppose I had previously sent:
c=IN IP4 10.1.1.2/127
m=image 54111 TCP t38
a=direction:passive
a=sendrecv
and had received the following in response:
c=IN IP4 10.1.1.1/127
m=image 9 TCP t38
a=direction:active
a=sendrecv
and now I want to hold this media stream. I could perhaps send the
following in a reinvite:
c=IN IP4 10.1.1.2/127
m=image 54111 TCP t38
a=direction:passive
a=sendonly
and expect to receive the following in response:
c=IN IP4 10.1.1.1/127
m=image 9 TCP t38
a=direction:active
a=recvonly
Here the only thing that has changed is a=sendrecv becoming a=sendonly
and a=recvonly. But something else may be implied by this reinvitation -
perhaps I should again listen on port 54111 and the other guy should do
another connect, with us then replacing the old socket connection with
the new one. This is what would have to happen if the c= line changed,
or perhaps if the port changed. It would be a bad thing if I assumed
that we should continue to use the existing connection, and don't bother
to listen, while the other end assumes it should do a new connect.
So it seems that there must be some additional specification regarding
if and when an existing connection can be reused following a reinvite.
Paul Kyzivat
Cisco Systems
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
