[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] [Sip-implementors] 200 OK response for hold with different media capabilities

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.

Avasarala Ranjit-A20990 wrote:

Hi Paul

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. 


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.
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. 


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?
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


Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent: Tuesday, August 25, 2009 12:07 AM 
To: Avasarala Ranjit-A20990
Cc: sunil.bhagat at wipro.com; sip at ietf.org;
sip-implementors at lists.cs.columbia.edu; sip at core3.amsl.com
Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold with
different media capabilities



Avasarala Ranjit-A20990 wrote:
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. 

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


Regards
Ranjit


________________________________
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of sunil.bhagat at wipro.com 
Sent: Monday, August 24, 2009 3:25 PM
To: sip at ietf.org; sip-implementors at lists.cs.columbia.edu;
sip at core3.amsl.com
Subject: [Sip] 200 OK response for hold with different media capabilities 



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

_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors