I'm not an expert on this, but I think what should happen is: - the server receives the 100 and can match it to no transaction - since 100 is handled hop by hop, the server just drops it.
You don't show what happens after that. But lets continue: - User B then sends 180 - the server receives the 180 and can match it to no transaction. - proxy rules (assuming server is a proxy) say that in this case it should forward the response as a stateless proxy would - User A receives the 180 and can match it to no transaction - so User A drops the 180 - eventually User B sends some final response - server forwards the response statelessly - User A ignores the response - User B retransmits the final response a few times but never receives an ACK - User B finally gives up on the transaction. Henrik Antonsson wrote: > Thanks for your answers. > Ok so I understand that 481 is not applicable for the INVITE. My question is > more what should be the correct behaviour for the client when the server > ignores 1xx. I will clarify my scenario: > > User A Server User B > | INVITE | | > |------------------->| ---- | > | |--------------> | | (User B is blocked and the > INVITE request is > | | | ---- | queued in the network) > | | | | > | | | | > | | | | > | | | | > | 408 TIMEOUT | | | > |<-------------------| | | > | | | | > | | |------->| (User B recieves a late INVITE) > | | 100 TRYING | > | |<-----------------| > | | | | > > Here is my problem, maybe I can blaim the network though but User B have no > idea that the transaction does no longer exist. I was hoping that the server > should respond to the 100 from User B but as you said that don't happen. > The only way to resolve this state is to wait for a timeout when sending the > 200 OK, is that correct? > > BR > anton > > > On Thu, May 29, 2008 at 2:55 PM, <[EMAIL PROTECTED]> wrote: > >> Few comments inline... >> >> Thanks, >> Nataraju A B >> ESN: 6-877-8567 >> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On >>> Behalf Of Henrik Antonsson >>> Sent: Thursday, May 29, 2008 5:58 PM >>> To: [email protected] >>> Subject: [Sip-implementors] 1xx response for a non-existing >>> transaction? >>> >>> Hi >>> >>> I've read some specifications on SIP but I can't find >>> anything about what should happend if a client sends a 1xx to >>> the server when the transaction no longer exists. >>> My scenario is that the INVITE from A to B is queued in the >>> network, the server tries and then timeout and sending A a >>> 408 response. At this state the transaction no longer exists >>> a suppose. When eventually B receives the INVITE (as it was >>> buffered in the network) how does B find out that the >>> transaction does not exist? B sends 100 TRYING and 180 >>> RINGING and 200 OK if the user accepts. Do I have to wait for >>> the timeout as the there will be no ACK from the server from >>> the 200 OK or should the server respond with 481 or any other >>> code when B sends 1xx codes? >>> >> [ABN] I am not sure I understood your question correctly. Here are few >> pointers in the similar lines... >> >> [ABN] client would never send out 1xx response in any cases. Till the >> server receives INVITE, where is question waiting for INVITE txn. The >> server side processing starts only when the INVITE message is received. >> >> 481 would never be applicable for initial (dialog creating) INVITE >> transaction. It would be applicable for mid dialog requests, for >> instance BYE, UPDATE, PRACK requests after the dialog is created. >> >> If the issue was INV, 200, and followed no ACK reply. Then the expected >> behavior is to terminate the call with BYE/200 transaction. The call >> should be terminated, whether 481/200 received for BYE request. >> >>> Thanks >>> anton >>> _______________________________________________ >>> Sip-implementors mailing list >>> [email protected] >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>> >> Please do not print this email unless it is absolutely necessary. >> >> The information contained in this electronic message and any attachments to >> this message are intended for the exclusive use of the addressee(s) and may >> contain proprietary, confidential or privileged information. If you are not >> the intended recipient, you should not disseminate, distribute or copy this >> e-mail. Please notify the sender immediately and destroy all copies of this >> message and any attachments. >> >> WARNING: Computer viruses can be transmitted via email. The recipient >> should check this email and any attachments for the presence of viruses. The >> company accepts no liability for any damage caused by any virus transmitted >> by this email. >> >> www.wipro.com >> > _______________________________________________ > 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
