Hi Somesh! RFC 3261 does not say "May have same callid as previous one". I quote from Section 8.1.3.5, Processing 4xx Responses.
In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. With other 4xx responses, including those yet to be defined, a retry may or may not be possible depending on the method and the use case. Otherwise, we end up with the [INVITE]-[407]-[ACK] loop since the proxy will re-issue a fresh 407 for the fresh INVITE. Warm Regards, Jerry Ipe Thomas Engineer (R&D) D-Link India Ltd. Software and R&D Center #65, 35th Main 100 ft. Ring Road 2nd Stage, B.T.M Layout Bangalore - 560068 -----Original Message----- From: somesh s [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 5:12 PM To: [email protected] Subject: Re: [Sip-implementors] SIP Proxy Authentication Hi, The F1, F2, F3 will close the INVITE transaction. So the F4 is supposed to be fresh invite (May have same callid as previous one) and supposed to be challenged again with 407 for which again ACK has to be issued and closed. Correct me if I am wrong. With regards Somesh S. Shanbhag --- Matthew Gardiner <[EMAIL PROTECTED]> wrote: > Hi all, > > I am currently researching how to implement the > client side of SIP > authentication in our system. I was wondering what > should happen if a client > sends F1 (INVITE with no credentials) and receives > F2 "407 Proxy > Authorization Required". Suppose the client > resubmits an INVITE, F4, with > credentials (that is, a Proxy-Authorization header > with a response parameter > is embedded), but the credentials supplied are > actually invalid. How then is > the proxy likely to respond? In other words in the > flow below what would F5 > be? > > > Alice Proxy Bob > | | | > | INVITE F1 | | > |----------->| | > | 407 Proxy Authorization Required F2 > |<-----------| | > | ACK F3 | | > |----------->| | > | INVITE F4 | | > |----------->| | > | ? F5 | | > |<-----------| | > | | | > | | | > > > (If F5 were another 407 message, then the client > should *probably* have the > intelligence to parse this, and deduce that it's > previous credentials were > invalid and give up. Were the client to dumbly > resubmit another INVITE then > an infinite loop could result). > > Any advice on this scenario would be appreciated. > > Thanks, > > Matthew Gardiner > Software Engineer > Aculab > Tel: +44 (0) 1908 273 911 > Fax: +44 (0) 1908 273 801 > Email: mailto:[EMAIL PROTECTED] > Website: <http://www.aculab.com> > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > ------------------------------- SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. ------------------------------- Somesh S. Shanbhag Mascon Global Communication Technologies Enterprise of Mascon Global Limited #59/2, 100Ft Ring Road Banashankari II stage Bangalore-560070 Karnataka INDIA Website: http://www.masconit.com ------------------------------- __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
