shamik.s...@wipro.com wrote:
> Hi Paul,
>
> When the re-invite reaches the other end will it searches for the best
> bandwith codec again from the offered codecs even if the VERSION number
> is the same in the re-invite as the original invite.
I don't know if it *will*, but it MAY.
Thanks,
Paul
> Thanks and regards,
>
> Shamik Saha
> Project Engineer
> Voice Protocols
> Cell : +91-9886704155
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
> Sent: Thursday, June 04, 2009 9:05 PM
> To: Attila Sipos
> Cc: Shamik Saha (WT01 - Telecom Equipment);
> sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] SDP in Session Refresh Request
>
>
>
> Attila Sipos wrote:
>> One more thing.
>>
>> I have seen UAs refresh the session using an UPDATE without any SDP.
>> Doing it this way doesn't change any of the codecs.
>>
>> RFC 4028 says:
>> It is RECOMMENDED that the UPDATE request not contain an
>> offer [4], but a re-INVITE SHOULD contain one, even if the details
> of
>> the session have not changed.
>>
>> so I think this would be ok, wouldn't it?
>
> Yes, IMO this is the preferred approach for a simple refresh if the
> parties support UPDATE.
>
> Thanks,
> Paul
>
>> -----Original Message-----
>> From: sip-implementors-boun...@lists.cs.columbia.edu
>> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
>> Paul Kyzivat
>> Sent: 03 June 2009 16:42
>> To: shamik.s...@wipro.com
>> Cc: sip-implementors@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] SDP in Session Refresh Request
>>
>> It wasn't stated who is doing the reinvite, and that can make a
>> difference.
>>
>> Also, there is nothing special about a reinvite used for session timer
>
>> refresh vs any other reinvite. Only the sender of the reinvite knows
>> why it was sent, and reinvites that are primarily for some other
>> purpose also refresh (or cancel) the session timer.
>>
>> If the sender of the reinvite has no motivation for doing so other
>> than refreshing the session timer, or simply verifying the state of
>> the session, then it could:
>> - send the same sdp it did the last time
>> - send an offer reflecting how it would like the session to be
>>
>> What it should not do is make an offer that anticipates what it thinks
>
>> the other party wants, based on what it has seen as responses from the
>
>> other party. Doing so can get into some nasty states, not so much with
>
>> codecs, but with other stuff, like sendonly/recvonly. Also, you can
>> never be certain that circumstances haven't changed at the other end.
>>
>> So, if UA1 is sending the reinvite, if it still would prefer to use
>> codec B or C, then it should probably offer them again, in addition to
>
>> A. But it might prefer not to do that if the change would cause some
>> added cost, pain, or poor user experience. For instance it it would
>> require renegotiating QoS, that might be a reason not to offer a
> change.
>> IF, after it decides what it wants to offer, that turns out to be the
>> same as what it sent last, then it should set the o-line the same as
>> last time.
>>
>> You should also check out
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer
>> -1
>> 0.txt
>>
>> Thanks,
>> Paul
>>
>>
>> shamik.s...@wipro.com wrote:
>>> Hi,
>>>
>>> I think you mean to say that the re-invite is send before the session
>
>>> timer expires as otherwise the session will be terminated,I think
>>> this
>>> re-invite should only contain codec A as it is the codec that has
>>> been
>>> negotiated,and the media streams for the other codec has been
>>> rejected
>>> by the far-end so your SDP can contain all the three codecs but only
>>> codec A should be ACTIVE.
>>>
>>> Since the two-peer has locked down on codec A,I think this should be
>>> the only active codec as the far end has not mentioned the other
>>> codec's in his answer so we can be sure that there will be no change
>>> of codec on the fly.
>>>
>>> To sum up,codec A can be the only active codec while B and C are
>>> inactive.
>>>
>>>
>>>
>>> Thanks and regards,
>>>
>>> Shamik Saha
>>> Project Engineer
>>> Voice Protocols
>>> Cell : +91-9886704155
>>>
>>> -----Original Message-----
>>> From: sip-implementors-boun...@lists.cs.columbia.edu
>>> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
>>> Radha krishna
>>> Sent: Tuesday, June 02, 2009 4:09 PM
>>> To: sip-implementors@lists.cs.columbia.edu
>>> Subject: [Sip-implementors] SDP in Session Refresh Request
>>>
>>>
>>> Hi All
>>>
>>> What should be the SDP in the following scenario.
>>>
>>> 1) UA1: Send INVITE with 3 codec's. A, B and C.
>>> 2) UA2: Received 200 with Codec A.
>>> 3) UA1: Session timer expired.
>>> 4) UA1: Sending Re-INVITE what should SDP contain?
>>> According to RFC we should not change SDP's, so o-line
>>> version MUST be same as
>>> initial INVITE, What about Codec? It should have A, B and
>
>>> C or just A.
>>> I think it should contain all three A, B and C right?
>>>
>>> Regards
>>> S.Radha krishna
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> Sip-implementors@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>> 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
>>
>
> 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
