Things I forgot to say the first time:
If the original INVITE contains an Expires header, then the UAS is
supposed to abandon the call when the time expires. Where the sip server
is a B2BUA, it is technically the UAS, so it should do it. BUT, the
implementor of the UAC is stupid to *depend* on this. If it wants the
call to end after that long, and it doesn't observe the call being
ended, then it should go ahead and do it.
And a NIT: the subject says this is a query about SDP. It has *nothing*
to do with SDP.
Paul
Paul Kyzivat wrote:
>
> [EMAIL PROTECTED] wrote:
>> Hi All,
>>
>>
>>
>> I have a query related to timeout case from the sip client side .
>>
>>
>>
>> User A and User B are registered to a sip server which is running a
>> back to back user agent.
>>
>> User A calls User B , and user B does not answer the call i.e., it will
>> be ringing and ringing.. .Then here who should send the timeout(i.e.,
>> CANCEL request) the sip client (user B) or the sip server.
>
> This is implementor's choice.
>
> IMO the UA for User A should send a cancel when its user gives up and
> hangs up the phone. Or in some cases it may want to do so sooner for
> reasons of its own. (E.g. a power issue.)
>
> The server can send a cancel if/when its local policies say it should.
> This could be because of a feature such as voicemail, or simply because
> it wants to reclaim its resources.
>
> And the UA for User B can choose to ring forever until canceled or
> answered, or it can choose to terminate the based on its own policies.
> (I hear that some devices will overheat if they ring too long.)
>
> Paul
>
>> Please suggest me in this regard.
>>
>>
>>
>> Thanks & Regards
>>
>> Rajeswari.R
>>
>>
>>
>>
>>
>> This e-mail and any files transmitted with it are for the sole use of the
>> intended recipient(s) and may contain confidential and privileged
>> information.
>> If you are not the intended recipient, please contact the sender by reply
>> e-mail and destroy all copies of the original message.
>> Any unauthorised review, use, disclosure, dissemination, forwarding,
>> printing or copying of this email or any action taken in reliance on this
>> e-mail is strictly
>> prohibited and may be unlawful.
>>
>>
>> _______________________________________________
>> 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
