IMO you can do as you wish. But to maximize interop you probably don't 
want to reject the call.

The assumption was that the UAC supported but didn't require session 
timer. So just accepting the call and *not* acting as refresher will 
suit its needs. But if there is a proxy in the middle that is expecting 
a refresh, and the UAS *isn't* going to do it, then that may cause some 
difficulty.

If the UAC decides to act as a refresher, things will still work out 
even if the UAS also decides to act as refresher. If they both decide to 
refresh at exactly the same time then you might get glare, but there are 
recovery procedures for that. To minimize the chance of that, the UAC 
could adjust the time it plans to do the refresh a little bit, to skew 
it from what the UAS is likely to try.

        Thanks,
        Paul

Rockson Li (zhengyli) wrote:
> Shane,
> 
> I think not to end the call might be fine.
> But to act as if "refresher=uac" is received might be troublesome,
> Since UAC does not know if UAS decides to refresh itself, 
> in that case, you would end up with glare re-INVITE when both sides
> intend to refresh later.
> 
> I think it would be better to assume "refresher=uas" being received.
> 
> Regards,
> -Rockson
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Shane Lee
> Sent: Thursday, October 09, 2008 7:38 PM
> To: Suganya D
> Cc: Govardhana Sankanna Nagendraprasad;
> [email protected]
> Subject: Re: [Sip-implementors] UAC's behavior upon receiving 200 OK
> forINVITEwithout Refresher
> 
> Hi,
> 
> For better interoperability, I don't think it is a good idea to reject
> the call. I agree with Anuradha, the caller had better continue the call
> and act as if "refresher=uac" is received.
> 
> Best Regards
> Shane
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to