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

Reply via email to