Subject: [Sip] 200 OK response for hold with different media capabilities

From: <[email-masked]>
Date: Mon, 24 Aug 2009 15:25:28 +0530

Hi All,

I have a small query related to HOLD request being sent out.

For a hold request, can gateway respond with different media
capabilities in 200 OK response?

Is the HOLD treated as any normal Re-INVITE?

Regards,

Sunil.

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 

www.wipro.com

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Mon, 24 Aug 2009 19:04:11 +0800

no it should not. For a Hold request, you do not send any media
capabilities. U only change the existing media description lines to
indicate HOLD.

Regards 
Ranjit 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, August 24, 2009 3:25 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: [Sip] 200 OK response for hold with different media
capabilities

Hi All,

Regards,

Sunil.

The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email. 

www.wipro.com

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Mon, 24 Aug 2009 19:04:11 +0800

Regards 
Ranjit 

Hi All,

Regards,

Sunil.

www.wipro.com

---

From: Vikram Chhibber <[email-masked]>
Date: Mon, 24 Aug 2009 11:05:01 -0700

The gateway can respond with different media capabilities in 200 OK
response for offer-less INVITE not for offer
that we view as for hold.
The gateway should create response as per rules defined in RFC 3264.
As far as SIP signalling is concerned, hold INVITE request is treated
as a regular re-INVITE request.

On Mon, Aug 24, 2009 at 2:55 AM, <[email-masked]> wrote:
> For a hold request, can gateway respond with different media capabilities in
> 200 OK response?
>
>
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
>
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: Vikram Chhibber <[email-masked]>
Date: Mon, 24 Aug 2009 11:05:01 -0700

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Aug 2009 14:36:37 -0400

> capabilities. U only change the existing media description lines to

I beg to differ.

Technically there is no HOLD request.
All there is is an offer that offers to change a media attribute, from 
sendrecv to sendonly or inactive, or from sendonly or recvonly to inactive.

The response may change anything that is permitted to be changed in the 
answer, given the offer. So it may not add m-lines, but it can certainly 
change media addresses, and within limits may change media formats (codecs).

	Thanks,
	Paul

> Sip-implementors mailing list
> [email-masked]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Aug 2009 14:36:37 -0400

I beg to differ.

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 25 Aug 2009 09:42:55 +0800

Hi Paul

The HOLD request is nothing but a re INVITE request indicating HOLD.

Could you give a use case where such a thing may happen? I have not come
across any scenario where in the process of putting remote party on
HOLD, media parameters like IP/codec getting changed.  If this happens,
then it cannot be considered a HOLD request.

So how do u distinguish a HOLD request from a non HOLD one if in both
the cases the media parameters (other than a=.....) change?

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2009 12:07 AM
To: Avasarala Ranjit-A20990
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold with
different media capabilities

I beg to differ.

Technically there is no HOLD request.
All there is is an offer that offers to change a media attribute, from
sendrecv to sendonly or inactive, or from sendonly or recvonly to
inactive.

The response may change anything that is permitted to be changed in the
answer, given the offer. So it may not add m-lines, but it can certainly
change media addresses, and within limits may change media formats
(codecs).

	Thanks,
	Paul

> The information contained in this electronic message and any 
> attachments to this message are intended for the exclusive use of the 
> addressee(s) and may contain proprietary, confidential or privileged 
> information. If you are not the intended recipient, you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately and destroy all copies of this message and any
attachments.

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 25 Aug 2009 09:42:55 +0800

Hi Paul

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2009 12:07 AM
To: Avasarala Ranjit-A20990
Cc: [email-masked]; [email-masked];

I beg to differ.

	Thanks,
	Paul

attachments.

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 25 Aug 2009 09:44:21 +0800

Hi Vikram

Gateway can respond with media capabilities to a offer less INVITE if it is acting as a 3PCC, not otherwise.  

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vikram Chhibber
Sent: Monday, August 24, 2009 11:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold withdifferent media capabilities

The gateway can respond with different media capabilities in 200 OK response for offer-less INVITE not for offer that we view as for hold.
The gateway should create response as per rules defined in RFC 3264.
As far as SIP signalling is concerned, hold INVITE request is treated as a regular re-INVITE request.

On Mon, Aug 24, 2009 at 2:55 AM, <[email-masked]> wrote:
> immediately and destroy all copies of this message and any attachments.
>
> should check this email and any attachments for the presence of 
> viruses. The company accepts no liability for any damage caused by any 
> virus transmitted by this email.
>
> www.wipro.com
>
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
>

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 25 Aug 2009 09:44:21 +0800

Hi Vikram

Regards
Ranjit

---

From: aayush bhatnagar <[email-masked]>
Date: Tue, 25 Aug 2009 02:53:21 +0000

Once the media streams(which are encoded in a set of codecs negotiated
earlier) have requested to be put on hold, then the answer should not
try to change any media attributes or codecs (that were negotiated
earlier).

By providing a different codec set in response to a HOLD request would
be equavalent to modifing the media characteristics of the current
session, not putting the media on hold.

On 25/08/2009, Avasarala Ranjit-A20990 <[email-masked]> wrote:
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Vikram
> Chhibber
> The gateway can respond with different media capabilities in 200 OK response
> for offer-less INVITE not for offer that we view as for hold.

-- 
aayush
----------------------------------------------------
"A philosopher always knows what to do...until it happens to him"

---

From: aayush bhatnagar <[email-masked]>
Date: Tue, 25 Aug 2009 02:53:21 +0000

---

From: Vikram Chhibber <[email-masked]>
Date: Mon, 24 Aug 2009 20:59:49 -0700

> Gateway can respond with media capabilities to a offer less INVITE if it is acting as a 3PCC, not otherwise.
This is exactly what I wrote in my mail.
I would again emphasize Paul’s comment. “Hold” is application’s
interpretation of some values in SDP such as offer with a =
sendonly/inactive. There is no such SDP called as hold SDP.
Furthermore,  this offer should be processed as a normal offer as
there could be a change in IP/port, codecs or codecs attributes.

---

From: Vikram Chhibber <[email-masked]>
Date: Mon, 24 Aug 2009 21:03:17 -0700

>> Gateway can respond with media capabilities to a offer less INVITE if it is acting as a 3PCC, not otherwise.
A small correction here. I do not know what Gateway you are talking
about here. For me, a gateway is a SIP end-point and would respond
with its media capabilities for offer-less INVITE.

---

From: Vikram Chhibber <[email-masked]>
Date: Mon, 24 Aug 2009 21:03:17 -0700

---

From: Vikram Chhibber <[email-masked]>
Date: Mon, 24 Aug 2009 20:59:49 -0700

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Aug 2009 11:28:21 -0400

I'm removing the cross posting to the sip list.
Cross posting is unpolite to those who subscribe to both lists.
And this topic is appropriate to sip-implementors.

> The HOLD request is nothing but a re INVITE request indicating HOLD.

There is no such thing as a reINVITE request that indicates *HOLD*.
There are indications for sendrecv, sendonly, recvonly, and inactive.
They are often used by UAs that have a HOLD feature, but they are also 
used for other purposes unrelated to HOLD features.

When a UAC implements a HOLD feature by sending a reINVITE with 
a=sendonly, the UAS does not know that the reason for this change is 
because of a HOLD feature. It can only take the signaling at face value:

"My peer wants to send me media, but doesn't want to receive it. Given 
that constraint, what do I want to do?"

There can be many answers to that question. There are no rules that say: 
thou shalt not change media attributes in this case.

> then it cannot be considered a HOLD request.

Its probably good advice that in general when being presented with an 
offered change you should respond with an answer that makes the minimal 
changes on your part that are consistent with what was offered. But that 
behavior isn't required.

I have heard of implementations that change media port on every 
reINVITE. Doesn't make sense to me, but maybe it did to them, and its 
within the rights of the implementor to do so.

> the cases the media parameters (other than a=.....) change?

As the recipient, you *don't* distinguish a HOLD request from a non HOLD 
one. You simply take things at face value without attempting to ascribe 
a reason for *why* they have happened.

	Thanks,
	Paul

> viruses.