Rajani wrote:
> In SDP body for each media line we have its media attribute values set below
> the media line. Each of them have default values if its not mentioned
> explicitly in the body..
>
> "If an offered media stream is
> listed as sendrecv (or if there is no direction attribute at the
> media or session level, in which case the stream is sendrecv by
> default), the corresponding stream in the answer MAY be marked as
> sendonly, recvonly, sendrecv, or inactive."
>
> Media direction attribute "a=sendrecv" is the default value if its not
> present for the particular media.
>
> a=<attribute>:<value>
> Attributes may be defined at "session-level" or at "media-level" or both.
> Session level attributes are used to advertise additional information that
> applies to conference as a whole. Media level attributes are specific to the
> media, i.e. advertising information about the media stream.
> So, in case 1 I think when a= sendonly is present at the session level, then
> it will hold the connection for both audio and video.
That would imply that the session level overrode the media level.
But the converse it true. The session level value just overrides the
default that will be used for any media stream that doesn't have a
media-level value.
So the cases shown work out as follows:
Case: Case 1: Case 2: Case 3:
-------- -------------- -------------- --------------
Session: sendonly sendonly sendrecv
audio: none(sendonly) none(sendonly) none(sendrecv)
video: sendonly sendrecv sendonly
But I suspect this is not the question that is being asked.
I think the question was intended to be:
"If I push the HOLD button on the video phone, does it hold audio,
video, or both?"
If that is the question, then neither SIP nor SDP can answer it.
This is a question of UI design. You might have separate buttons for
each, or one button for both, or whatever.
If you are on the receiving side of a change like this you should make
no assumptions about which combinations you might see. Any are possible.
And of course whether session level or media level attributes are used,
in what combination, is also entirely flexible.
Thanks,
Paul
> If we want to hold only the video stream, then probably we have to include
> a=sendonly attribute only for video media lines as in case 3...
>
> Thanks & Regards,
> Rajani
>
> -----Original Message-----
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> Lakshminarayana Jayaprakash
> Sent: Friday, July 17, 2009 3:23 AM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] SIP video Hold
>
> Hi,
>
> Is there a convention how SIP video terminal should do call hold?
> Case-1: [Hold for both audio and video streams]
> c=IN IP4 a.b.c.d
> a=sendonly
> m=audio
> ...
> m=video
> c=IN IP4 p.q.r.t
> a=sendonly
>
> Case-2: [Hold for audio stream only]
> c=IN IP4 a.b.c.d
> a=sendonly
> m=audio
> ...
> m=video
> c=IN IP4 p.q.r.t
> a=sendrecv
>
> Case-3: [Hold for video stream only]
> c=IN IP4 a.b.c.d
> a=sendrecv
> m=audio
> ...
> m=video
> c=IN IP4 p.q.r.t
> a=sendonly
>
>
> Questions:
> 1. Is the hold specified for both audio and video streams or one of
> them?
> 2. If case-2 and case-3 are possible, should the call be considered
> as hold?
>
> Thanks in advance.
>
> Regards,
> JP
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
