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
