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:pkyzi...@cisco.com]
> Sent: Tuesday, August 25, 2009 12:07 AM
> To: Avasarala Ranjit-A20990
> Cc: sunil.bha...@wipro.com; s...@ietf.org;
> sip-implementors@lists.cs.columbia.edu; s...@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-boun...@ietf.org [mailto:sip-boun...@ietf.org] On Behalf Of
>> sunil.bha...@wipro.com
>> Sent: Monday, August 24, 2009 3:25 PM
>> To: s...@ietf.org; sip-implementors@lists.cs.columbia.edu;
>> s...@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@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
