Henrik Antonsson wrote:
> 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.
You didn't confirm that the server is a proxy. (Alternatively it might
be a B2BUA.)
If it is a proxy, then I am pretty sure it is supposed to forward the
180 statelessly rather than drop it. As you say, it doesn't affect the
outcome, but still it is wrong.
> I was hoping that the server could notify User B when it he tries to
> continue the transaction that does no longer exist.
What sort of notification were you hoping for? There are no responses to
responses, other than the ACK that comes after final response to INVITE,
and PRACK for a reliable provisional response. Neither of these work here:
- proxy can send ACK to a final error response, but there has been
no final response.
- ACK is never sent after provisional response
- PRACK is only sent in response to receipt of reliable provisional
response by the UAC. 100 responses are never reliable, and even if
B sent a reliable 180, only the UAC could PRACK it. And the UAC
would not do that if it had no transaction. (Actually must have an
early dialog.)
So there is nothing that *can* be sent.
Paul
> 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]
> <mailto:[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]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Few comments inline...
>
> Thanks,
> Nataraju A B
> ESN: 6-877-8567
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> [mailto:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>] On
> Behalf Of Henrik Antonsson
> Sent: Thursday, May 29, 2008 5:58 PM
> To: [email protected]
> <mailto:[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]
> <mailto:[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 <http://www.wipro.com>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> <mailto:[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
