Ring time timer should be started in TU ( implementation specific). 
Shouldnt the endpoing issue CANCEL on expiry of it ??


On Tue, 22 Feb 2005 16:47:52 -0800, Poojan Tanna <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> RFC#3261 is not clear whether Timer-B is applicable to Proceeding State.
> Most of the implementation that I have seen Timer-B is applicable to
> Proceeding state as well.
> 
> Regarding changing the T1 value. I am not sure how feasible is this
> solution. Since it not affects Timer-B but also other transaction
> timers.
> For example Timer A which controls request retransmissions also uses T1
> timer.
> 
> Again, the ringing duration is implementation specific and 480 is most
> preferred/used response.
> 
> Thanks,
> Poojan.
> 
> 
> David Monahan wrote:
> >
> > Hi,
> >
> > I think the ringing duration is implementation dependent as previously
> > stated. Have a look at "603 Decline" as a possible response - this is
> > used in 3GPP SIP mappings for "no answer".
> >
> > "21.6.2 603 Decline
> > The callee's machine was successfully contacted but the user explicitly
> > does not wish to or cannot participate.  The response MAY indicate a
> > better time to call in the Retry-After header field.  This status
> > response is returned only if the client knows that no other end point
> > will answer the request."
> >
> > Rgds,
> > David
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > >
> > >
> > > Hi Attila,
> > >
> > > "480 Temporarily Unavailable" is not used for this purpose
> > >
> > > RFC 3261
> > > 16.5 Determining Request Targets:
> > > If the target set remains empty after applying all of the above, the
> > > proxy MUST return an error response, which SHOULD be the 480
> > > (Temporarily Unavailable) response.
> > >
> > > So According to the RFC 3261, It will ring for ever
> > >
> > > Following is the thread from sip-implementors
> > >
> > >
> > > http://lists.cs.columbia.edu/pipermail/sip-implementors/2002-July/003390.html
> > >
> > > But again it is in end point control, but in PSTN it is network control.
> > > This kind of functionality should be in network control.
> > >
> > >
> > > Regards,
> > > Thangarajan.
> > >
> > >
> > >
> > >              "Attila Sipos"
> > >              <[EMAIL PROTECTED]
> > >              astream.com>                                               To
> > >                                        <[EMAIL PROTECTED]>,
> > >              02/22/05 08:18 PM         <[email protected]>
> > >                                                                         cc
> > >
> > >                                                                    Subject
> > >                                        RE: [Sip-implementors] Ringing time
> > >                                        -- Endpoint or Network
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi Thangarajan,
> > >
> > > How long you want the destination UA to ring for depends
> > > on the implementation.
> > >
> > > Normally UA's have some kind of configuration variable
> > > so that they can specify how long they should ring for.
> > > If the call is not answered with that time period,
> > >      the destination UA will usually issue a
> > > "480 Temporarily Unavailable" response.
> > > (see RFC3261 for details on 480 response)
> > >
> > > Regards,
> > >
> > > Attila
> > >
> > > Attila Sipos
> > > http://www.vegastream.com
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: [EMAIL PROTECTED]
> > >>[mailto:[EMAIL PROTECTED] Behalf Of
> > >>[EMAIL PROTECTED]
> > >>Sent: 22 February 2005 12:42
> > >>To: [email protected]
> > >>Subject: [Sip-implementors] Ringing time -- Endpoint or Network
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>Hi,
> > >>
> > >>      INVITE
> > >>UAC --------------------------->UAS
> > >>      180 Ringing
> > >>UAC <---------------------------UAS
> > >>
> > >>We did not have any timer in proceeding state, so how long it
> > >>has to ring
> > >>in the UAS end ?
> > >>
> > >>if we set some propriority time in UA, then end point will
> > >>have the control
> > >>over this time. But in PSTN network,  network is taking care of this
> > >>functionality, not endpoint.
> > >>
> > >>Whether this functionality  is take care by SIP Network ?
> > >>
> > >>Regards,
> > >>Thangarajan.
> > >>
> > >>
> > >>
> > >>***********************  HSS-Private   ***********************
> > >>"DISCLAIMER: This message is proprietary to Hughes Software
> > >>Systems Limited
> > >>(HSS) and is intended solely for the use of the individual to
> > >>whom it is
> > >>addressed. It may contain  privileged or confidential information and
> > >>should not be circulated or used for any purpose other than
> > >>for what it is
> > >>intended. If you have received this message in error, please
> > >>notify the
> > >>originator immediately. If you are not the intended recipient, you are
> > >>notified that you are strictly prohibited from using,
> > >>copying, altering, or
> > >>disclosing the contents of this message. HSS accepts no
> > >>responsibility for
> > >>loss or damage arising from the use of the information
> > >>transmitted by this
> > >>email including damage from virus."
> > >>
> > >>_______________________________________________
> > >>Sip-implementors mailing list
> > >>[email protected]
> > >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > >>
> > >
> > >
> > >
> > >
> > > ***********************  HSS-Private   ***********************
> > > "DISCLAIMER: This message is proprietary to Hughes Software Systems 
> > > Limited
> > > (HSS) and is intended solely for the use of the individual to whom it is
> > > addressed. It may contain  privileged or confidential information and
> > > should not be circulated or used for any purpose other than for what it is
> > > intended. If you have received this message in error, please notify the
> > > originator immediately. If you are not the intended recipient, you are
> > > notified that you are strictly prohibited from using, copying, altering, 
> > > or
> > > disclosing the contents of this message. HSS accepts no responsibility for
> > > loss or damage arising from the use of the information transmitted by this
> > > email including damage from virus."
> > >
> > > _______________________________________________
> > > Sip-implementors mailing list
> > > [email protected]
> > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> > --
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > David Monahan
> > AePONA Ltd
> > Interpoint Building, 20-24 York Street, Belfast BT15 1AQ
> > Email: [EMAIL PROTECTED]
> > Tel: +44 (0)28 9026 9160     Fax: +44 (0)28 9026 9111
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > _______________________________________________
> > Sip-implementors mailing list
> > [email protected]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 
> --
> -------------------------------------------------------------------------
> Poojan Tanna                             E-Mail: [EMAIL PROTECTED]
> Phone Office : 510-747-5282
> Home   : 510-569-8820
> -------------------------------------------------------------------------
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to