Yes, with the modification that the server drops the 180 and do not send it to user A, but the result is the same - User B has to wait for the timers to timeout to give up the transaction. I was hoping that the server could notify User B when it he tries to continue the transaction that does no longer exist. The result of this could be very un-user friendly, with a session invitation that will be removed only when User B gives up the transaction. In my opinion it is little a lack in the SIP protocol, please correct me if I am wrong.
Thanks for the help everybody /anton On Thu, May 29, 2008 at 5:14 PM, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > 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
