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

Reply via email to