Hi Puneet , I dont think it voilates any RFC .But UAS should indicate incoming call indication to UI after parsing only .
But if it comes this way ,still we should be able to handle this gracefully Also you should Retry with new INVITE if Retry-After comes in 480 . If Retry-After not coming then its application logic decision to send Invite or not . Also same call flow can be realised in Call forwarding scenario when user B rings and call forwarded to user C . Assume user C not available ,and 181 was not forwarded to A .Then 480 can come after 180 ringing . I know this will happen in worst case but still anything possible . Thanks & Regards Ankur Bansal On Fri, Sep 13, 2013 at 6:22 PM, Balint Menyhart <balme...@cisco.com> wrote: > Hi, > > I would suggest you do validation first, and if it succeeds, you send > 180 Ringing. > But sending 4xx after a 180 is legal. Best example for that is 487 > Request Terminated after the caller receives 180 Ringing and sends a > CANCEL. > > Balint > > > On 13/09/2013 13:14, Kumar, Puneet (Puneet) wrote: > > Hi All, > > > > Can any UAS send 18x response then a 4xx response ? > > > > Does any section of RFC violate it ? > > > > In my case a UAS is sending a 180 Ringing followed by a 480 response as > it do not support "sips" URI. > > Should I honor this 480 response & retry? > > > > Thanks, > > Puneet > > > > _______________________________________________ > > 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 > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
