No, UAS shouldn't assume that. The call (or session) is on hold only
when all media streams are on hold.
Strictly speaking, UAS can't assume anything to be on hold. It can't
make out whether it is ("sendonly") is for "hold" or if UAC intends to
convert the "sendrecv" to "sendonly" for some other reason. So, as far
as UAS is concerned, it replies with "recvonly" and "listens" to
whatever comes on media channel. If there is a PBX in between, it may
hear music or "the call is on hold" announcement. Or may hear nothing if
there's no PBX in between (and UAC doesn't send any media out when on
hold).
Hope this clarifies.
________________________________
From: JAYAPRAKASH LAKSHMINARAYANA [mailto:kandawar@ yahoo.com]
Sent: Tuesday, July 21, 2009 9:11 PM
To: T Satyanarayana-A12694; Lakshminarayana Jayaprakash; Paul Kyzivat;
Rajani
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SIP video Hold
Hi Satyanarayana,
Thanks.
Any thought on the first question?
>From the receiving end, should the UAS assume that the call is on hold
when it receives only one of the media streams on hold?
Regards,
J.P.
________________________________
From: T Satyanarayana-A12694 <satyanarayan...@motorola.com>
To: Lakshminarayana Jayaprakash
<jayaprakash.lakshminaray...@comverse.com>; Paul Kyzivat
<pkyzi...@cisco.com>; Rajani <choudhury.raj...@gmail.com>
Cc: sip-implementors@lists.cs.columbia.edu
Sent: Tuesday, July 21, 2009 10:55:46 AM
Subject: Re: [Sip-implementors] SIP video Hold
No, each stream is to be treated independently. i.e. the other streams
continue to have sendrecv in answer.
-----Original Message-----
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Lakshminarayana Jayaprakash
Sent: Tuesday, July 21, 2009 5:52 PM
To: Paul Kyzivat; Rajani
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SIP video Hold
Hi Paul,
Thanks for the response. My question is understood right.
>From the receiving end, should the UAS assume that the call is on hold
when it receives only one of the media streams on hold?
If the answer to the above question is yes, then is following the right
way to handle;
- Let's say if we receive a re-invite[SDP offer] with one of the media
streams on hold, should the SDP answer response be "recvonly" for the
other stream?
Regards,
J.P.
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
Sent: Monday, July 20, 2009 6:47 PM
To: Rajani
Cc: Lakshminarayana Jayaprakash; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SIP video Hold
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
_______________________________________________
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
