[SIPForum-discussion] session refresh parameter in response
Santhosh B.N
bnsanthosh89 at gmail.com
Wed Jun 20 11:11:25 UTC 2012
On receiving a Invite with refresher type parameter as none the Media
server itself shall take care of refreshing the session and act as
refresher ----- hence the refresher will be UAS ---- with one exception as
below
If the Media server (or any UAS for that matter) is configured in such a
way that the server will never take the role of refresher but supports
session refresh and wants the UAC from which the invite is received to be
refresher then the UAC will take the role of refresher, this happens when
refresher type on Media server/UAS is configured as "UAC"
config on UAC Config on UAS Who takes the role of Refresher
1) None none/UAS UAS
2) None UAC UAC
Thanks,
Santhosh
On Tue, Jun 19, 2012 at 7:49 PM, Sapan Vashishth
<sapan.vashishth at gmail.com>wrote:
> Hi all
>
> How is the refresh mode selected to be uas/ uac.
>
> For example if the invite to the (say media server) contains
> Supported: timer
> Session-Expires: 100
> and no refresh parameter, then how would the MS decide to the refresh mode
> be uac or uas. Is this decided on basis of some criteria?
>
> since the rfc 4028 says
>
> UAC supports? refresher parameter refresher parameter
> in request in response
> -------------------------------------------------------
> N none uas
> N uac NA
> N uas NA* Y none uas or uac*
> Y uac uac
> Y uas uas
>
> so in case the UAC supports the timer and refresh parameter is none then
> the refresher parameter can be any of uac or uas. so who decides that value
> from the two.
>
>
> BR
> Sapan
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20120620/0e510656/attachment-0002.html>
More information about the discussion
mailing list