Hi,
Sorry for confusion.
My question is if Re-Invite does not carry supported: timer (but
initial invite request had supported: timer), as per RFC because UAS should
not send 2xx response with UAC.
But initial Invite request had supported: timer.
What should be UAS behavior here?
UAS should send 2xx response with refresher as UAC or UAS.
Because as per RFC below highlighted text it MUST send with
refresher as UAS.
Let me know your opinion also.
****************************************************************************
****************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
Sent: Tuesday, June 28, 2011 7:46 PM
To: Ravi Kumar
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] no supported header in re-invite or
different value
Is there a question here?
Paul
On 6/28/2011 4:31 AM, Ravi Kumar wrote:
> Thank to Paul and Brett for reply.
>
>
> - session-timer negotiation is repeated in every reinvite and
> update. If it is not renegotiated to be on, then it is off.
> So in both your cases the session timer stops at the completion
> of the reinvite transaction.
>
> If Re-Invite request does not carry supported: timer, than UAS can not
have
> refresher as UAC in response.
> Refer to below text from RFC.
>
> As per RFC 4028
>
> UAC supports? refresher parameter refresher parameter
> in request in response
> -------------------------------------------------------
> N none uas
>
>
>
>
****************************************************************************
> ****************************
> This e-mail and attachments contain confidential information from
HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender
by
> phone or email immediately and delete it
>
> -----Original Message-----
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul
> Kyzivat
> Sent: Wednesday, June 22, 2011 10:13 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] no supported header in re-invite or
> different value
>
> Ravi,
>
> - there is *no* semantic difference between a Supported header
> that *doesn't* contain "timer" and the total absence of a
> Supported header.
>
> - session-timer negotiation is repeated in every reinvite and
> update. If it is not renegotiated to be on, then it is off.
> So in both your cases the session timer stops at the completion
> of the reinvite transaction.
>
> - a use case where renegotiation of session timer might make
> sense is when there is a B2BUA in the middle and it does
> a 3pcc transfer. But it doesn't really matter if there is a
> use case, this is how it works.
>
> Thanks,
> Paul
>
> On 6/22/2011 2:25 AM, Ravi Kumar wrote:
>> Hi All,
>>
>>
>>
>> 1.
>>
>>
>>
>> Caller Callee
>>
>>
>>
>>
>>
>> ---------INVITE---------------->
>>
>> supported: timer
>>
>> Session-Expires: 200
>>
>>
>>
>>
>>
>> <---------------200(INVITE)---
>>
>> supported: timer
>>
>> Session-Expires: 200;refresher=uac
>>
>>
>>
>> -----------ACK---------------------->
>>
>>
>>
>>
>>
>>
>>
>> ---------INVITE----------------> // Here callee should assume
> that
>> peer supports session timer or not because supported: timer is not
present
>> in request.
>>
>>
>>
>>
>>
>> 2.
>>
>>
>>
>> Caller Callee
>>
>>
>>
>>
>>
>> ---------INVITE---------------->
>>
>> supported: timer
>>
>> Session-Expires: 200
>>
>>
>>
>>
>>
>> <---------------200(INVITE)---
>>
>> supported: timer
>>
>> Session-Expires: 200;refresher=uac
>>
>>
>>
>> -----------ACK---------------------->
>>
>>
>>
>>
>>
>>
>>
>> ---------INVITE----------------> // Here callee should assume
> that
>> peer does not support session timer
>>
>> supported: 100rel
>>
>>
>>
>>
>>
>>
>>
>> a. Please let me know what should be correct behavior for
> above
>> both cases. And other SIP stack has implemented this.
>>
>> b. Application scenario where supported value is changed in
>> between the session.
>>
>>
>>
>>
>>
>> Thanks& Regards,
>>
>> Ravi Kumar
>>
>>
>>
>>
>>
>>
>
****************************************************************************
>> ****************************
>> This e-mail and attachments contain confidential information from
> HUAWEI,
>> which is intended only for the person or entity whose address is listed
>> above. Any use of the information contained herein in any way (including,
>> but not limited to, total or partial disclosure, reproduction, or
>> dissemination) by persons other than the intended recipient's) is
>> prohibited. If you receive this e-mail in error, please notify the sender
> by
>> phone or email immediately and delete it
>>
>>
>>
>> _______________________________________________
>> 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
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
