This is replying gto several messages in this thread:
First, what the original post showed seems entirely fine to me, though
it may not be "preferred". While there may be phones that will respond
poorly to this, they are *broken* and should be fixed. (Disclaimer: I
didn't study the messages in detail - just the general approach being
used.)
I say that such a phone is broken. Perhaps it is not if this can be
viewed as a *policy* to avoid being placed on hold. But I expect that
the phones not supporting this are not doing so for policy reasons.
It is generally "preferred" to use a=sendonly or a=inactive for such a
use. But the c=0 is also permitted. And this may be a case where there
is a good reason - it may be desired to avoid assigning resources for a
media stream at this time. You can use the "belt & suspenders" of
including both c=0 and a=inactive if you wish. That may make some UAs
happier.
regarding whether the hold is per-media or global, it can be either way.
The c=, a=sendonly and a=inactive can all be used eithre at session
level or media level. Session level versions of these apply if there is
no media level version.
Some examples (simplified to make the point, not valid syntax):
c=IN IP4 0.0.0.0
m=audio
...
m=video
The above has both audio and video streams on "hold". (We use the term
"black holed" for this.)
c=IN IP4 0.0.0.0
a=sendonly
m=audio
...
m=video
c=IN IP4 0.0.0.0
a=sendonly
m=audio
c=IN IP4 0.0.0.0
a=sendonly
...
m=video
c=IN IP4 0.0.0.0
a=sendonly
m=audio
c=IN IP4 0.0.0.0
a=sendonly
...
m=video
c=IN IP4 0.0.0.0
a=sendonly
c=IN IP4 10.238.115.216
m=audio
c=IN IP4 0.0.0.0
a=sendonly
...
m=video
c=IN IP4 0.0.0.0
a=sendonly
The above are all functionally equivalent to the prior case, but may
make somebody happier.
c=IN IP4 0.0.0.0
m=audio
...
m=video
c=IN IP4 10.238.115.216
In the above, audio is black holed, video is active
c=IN IP4 10.238.115.216
a=inactive
m=audio
...
m=video
This also puts both audio and video on "hold", but unlike the earlier
case it establishes the media streams but doesn't use them, except for RTCP.
c=IN IP4 10.238.115.216
m=audio
a=inactive
...
m=video
a=inactive
The above is functionally equivalent to the prior case.
Finally, I would like to point out that "hold" is an informal concept as
far as sip is concerned. There is no formal way for one UA to tell
another it is on "hold", or even a definition of what that means. All
that one UA can tell another is how it wishes to manage the media. The
concept of "hold" is really a local implementation and UI issue.
E.g. if you receive an INVITE with an offer like:
c=IN IP4 10.238.115.216
m=audio
a=sendonly
It *might* mean that the caller wants to put the callee on hold
initially. Or, it might mean the the caller has no capability to receive
audio, ever. (It may be intended solely to play out a message and then
disconnect.)
There is no way for the callee to know, which is a good reason not to
reject such calls.
Paul
[EMAIL PROTECTED] wrote:
> Hi
>
>
>
> Here I have a doubt with respect to whether a=inactive/sendonly is for
> whole sdp or for each mediaDescription.
>
>
>
> Could anyone please suggest me how to set the a=inactive/sendonly in the
> MediaDescription of the SessionDescription .Iam using NIST-SIP api for
> creating the SessionDescription.
>
>
>
> Thanks & Regards
>
> Rajeswari.R
>
>
>
> ________________________________
>
> From: Mahipati Deshpande [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 07, 2008 10:50 AM
> To: Routhu, Rajeswari (Cognizant);
> Sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] REG: call hold
>
>
>
> yes, you are right. And also a=inactive means its on hold.
>
>
>
> Regards,
> Mahipati Deshpande
>
>
>
> ----- Original Message ----
> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]; Sip-implementors@lists.cs.columbia.edu
> Sent: Wednesday, 7 May, 2008 10:25:38 AM
> Subject: RE: [Sip-implementors] REG: call hold
>
>
> Hi Deshpande,
>
> Many thanks for the reply.
>
> Iam using xlite as the user agent. The way I can confirm that a
> useragent is placed on hold is seeing a=recvonly right?
>
> Thanks & Regards
> Rajeswari.R
> Communications Practice | Cognizant Technology SolutionsIndia Pvt Ltd
> VNET: +1 973 368 9600 - 63149 | PSTN: +91.40.4451.3149| Mobile: +91
> 9246163098 | [EMAIL PROTECTED]
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Mahipati Deshpande
> Sent: Wednesday, May 07, 2008 10:21 AM
> To: Routhu, Rajeswari (Cognizant);
> Sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] REG: call hold
>
> Some phone does not support offer with hold. You should be prepared to
> handle this kind of scenario. You may try adding "a=sendonly" in your
> initial offer. This works with few phones.
>
> Regards,
> Mahipati Deshpande
>
> ----- Original Message ----
> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> To: Sip-implementors@lists.cs.columbia.edu
> Sent: Wednesday, 7 May, 2008 10:10:21 AM
> Subject: [Sip-implementors] REG: call hold
>
>
> Hi all,
>
>
>
>
>
> I want to connect to a useragent i.e, put him on hold from my
> application. The useragent is not on any call initially .For this iam
> creating an invite request and sending it to the useragent as below:
>
>
>
> INVITE sip:[EMAIL PROTECTED]:12000 SIP/2.0
>
> From:
> <sip:[EMAIL PROTECTED]>;tag=42215289471803874_local.1210132738140_10
> _10
>
> To: <sip:[EMAIL PROTECTED]>
>
> Call-ID: [EMAIL PROTECTED]
>
> Max-Forwards: 70
>
> CSeq: 2 INVITE
>
> Content-Type: application/sdp
>
> Content-Length: 159
>
>
>
> v=0
>
> o=user 0 0 IN IP4 10.238.115.216
>
> s=-
>
> c=IN IP4 0.0.0.0
>
> t=0 0
>
> m=audio 10000 RTP/AVP 0 101
>
> a=rtpmap:0 pcmu/8000/1
>
> a=rtpmap:101 telephone-event/8000/1
>
>
>
> For this the useragent is sending response as:
>
>
>
> SIP/2.0 200 OK
>
> Content-Length: 243
>
> User-Agent: X-Lite release 1002tx stamp 29712
>
> Content-Type: application/sdp
>
> Allow: INVITE
>
> Allow: ACK
>
> Allow: CANCEL
>
> Allow: OPTIONS
>
> Allow: BYE
>
> Allow: REFER
>
> Allow: NOTIFY
>
> Allow: MESSAGE
>
> Allow: SUBSCRIBE
>
> Allow: INFO
>
> CSeq: 2 INVITE
>
> Call-ID: [EMAIL PROTECTED]
>
> From:
> <sip:[EMAIL PROTECTED]>;tag=42215289471803874_local.1210132738140_10
> _10
>
> To: <sip:[EMAIL PROTECTED]>;tag=3861b74f
>
> Contact: <sip:[EMAIL PROTECTED]:12000>
>
> Via: SIP/2.0/UDP
> 10.238.115.216:5060;branch=z9hG4bK870573921493445;ibmsid=local.121013273
> 8140_10_10
>
>
>
> v=0
>
> o=- 1 2 IN IP4 10.238.115.216
>
> s=<CounterPath eyeBeam 1.5>
>
> c=IN IP4 10.238.115.216
>
> t=0 0
>
> m=audio 12002 RTP/AVP 0 101
>
> a=fmtp:101 0-15
>
> a=rtpmap:101 telephone-event/8000
>
> a=sendrecv
>
> a=x-rtp-session-id:CEAECAD8CCB04812A04FE6D267EEB9A0
>
>
>
> Iam creating the ACK for the response and sending it back and call got
> established with the server and the useragent.
>
>
>
> Now is it the right procedure to put a useragent on hold. If not please
> suggest me the correct procedure,
>
>
>
>
>
>
>
> Thanks & Regards
>
> Rajeswari.R
>
>
>
>
>
> This e-mail and any files transmitted with it are for the sole use of
> the intended recipient(s) and may contain confidential and privileged
> information.
> If you are not the intended recipient, please contact the sender by
> reply e-mail and destroy all copies of the original message.
> Any unauthorised review, use, disclosure, dissemination, forwarding,
> printing or copying of this email or any action taken in reliance on
> this e-mail is strictly
> prohibited and may be unlawful.
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
>
>
>
> Share files, take polls, and make new friends - all under one
> roof. Go to http://in.promos.yahoo.com/groups/
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> This e-mail and any files transmitted with it are for the sole use of
> the intended recipient(s) and may contain confidential and privileged
> information.
> If you are not the intended recipient, please contact the sender by
> reply e-mail and destroy all copies of the original message.
> Any unauthorised review, use, disclosure, dissemination, forwarding,
> printing or copying of this email or any action taken in reliance on
> this e-mail is strictly
> prohibited and may be unlawful.
>
>
>
>
>
>
>
>
>
> ________________________________
>
> Bring your gang together. Do your thing. Find your favourite Yahoo!
> Group.
> <http://in.rd.yahoo.com/tagline_groups_9/*http:/in.promos.yahoo.com/grou
> ps/>
>
>
>
> This e-mail and any files transmitted with it are for the sole use of the
> intended recipient(s) and may contain confidential and privileged information.
> If you are not the intended recipient, please contact the sender by reply
> e-mail and destroy all copies of the original message.
> Any unauthorised review, use, disclosure, dissemination, forwarding, printing
> or copying of this email or any action taken in reliance on this e-mail is
> strictly
> prohibited and may be unlawful.
>
>
> _______________________________________________
> 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
