Summary:ASTERISK-03536: Does asterisk respond correctly when it receives a 491 Request Pending
Reporter:ennuyeux72 (ennuyeux72)Labels:
Date Opened:2005-02-18 06:50:51.000-0600Date Closed:2011-06-07 14:10:23
Versions:Frequency of
Environment:Attachments:( 0) ethereal.out.2
( 1) incoming491.txt
( 2) incomingpstn_1.rtf
( 3) incomingpstn_1.txt
Description:Ok I am posting some tethereal trace of  a situation where a recent CVS seems not to behave right when it receives a 491 response to INVITE. I will elaborate but am not quite sure how to phrase all this,so am hoping someone out there will ask the right questions.

The architecture is as follows:


CAll comes in from PSTN to the user agent. The SIP-UA rings but as soon as he picks up the call it hangs up.

Initial viewing of the trace shows that Jasomi Peerpoint issues a 491 pending to an INVITE from asterisk and asterisk then seems to ultimately drop the call with a 403 forbidden.

If canreinvite in sip.conf is set to no then we have a workaround BUT means asterisk carries the media.
Comments:By: Olle Johansson (oej) 2005-02-18 07:22:03.000-0600

RFC3261, sec 14.1:
If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
  timer with a value T chosen as follows:

     1. If the UAC is the owner of the Call-ID of the dialog ID
        (meaning it generated the value), T has a randomly chosen value
        between 2.1 and 4 seconds in units of 10 ms.

     2. If the UAC is not the owner of the Call-ID of the dialog ID, T
        has a randomly chosen value of between 0 and 2 seconds in units
        of 10 ms.

  When the timer fires, the UAC SHOULD attempt the re-INVITE once more,
  if it still desires for that session modification to take place.  For
  example, if the call was already hung up with a BYE, the re-INVITE
  would not take place.
A UAS that receives a second INVITE before it sends the final
  response to a first INVITE with a lower CSeq sequence number on the
  same dialog MUST return a 500 (Server Internal Error) response to the
  second INVITE and MUST include a Retry-After header field with a
  randomly chosen value of between 0 and 10 seconds.

  A UAS that receives an INVITE on a dialog while an INVITE it had sent
  on that dialog is in progress MUST return a 491 (Request Pending)
  response to the received INVITE.

  If a UA receives a re-INVITE for an existing dialog, it MUST check
  any version identifiers in the session description or, if there are
  no version identifiers, the content of the session description to see
  if it has changed.  If the session description has changed, the UAS
  MUST adjust the session parameters accordingly, possibly after asking
  the user for confirmation.
21.4.27 491 Request Pending

  The request was received by a UAS that had a pending request within
  the same dialog.  Section 14.2 describes how such "glare" situations
  are resolved.

By: Olle Johansson (oej) 2005-02-18 07:24:03.000-0600

Ok, that was the SIP rfc on "491 pending"... Now, let's figure out what is happening. Can you please take a full SIP DEBUG output of the call so we can see the transaction from Asterisk's point of view. Set debugging level high, please.

I think this is due to the fact that we are sending a re-invite too quickly for the jasomi or that the jasomi is sending us a re-invite at the same time as we are. Please add a SIP debug trace and I'll look into this.

By: Olle Johansson (oej) 2005-02-18 07:27:42.000-0600

21.4 Request Failure 4xx

  4xx responses are definite failure responses from a particular
  server.  The client SHOULD NOT retry the same request without
  modification (for example, adding appropriate authorization).
  However, the same request to a different server might be successful.
That's how we treat unknown 4xx responses today. The error here is that we are hanging up the call, not giving up on the re-invite which should be the correct way of acting I guess. Waiting for a SIP debug until I place a verdict and start looking into the code...

By: Olle Johansson (oej) 2005-02-18 07:38:11.000-0600

I can't read you Ethereal dump with my Ethereal...

By: Mark Spencer (markster) 2005-02-18 08:34:17.000-0600

We would need to keep track I suppose of whether this was the original invite or not.  We already have "delayed reinvite" code there, but this will take some additional work.


When did SIP's operation actually seem like a good idea?

By: ennuyeux72 (ennuyeux72) 2005-02-18 11:02:59.000-0600

Ok am posting the asterisk sip debug

Calling incoming number 02070433288
Directing to SIP account:726002@acmetalk.net

By: ennuyeux72 (ennuyeux72) 2005-02-18 11:10:49.000-0600

the ethereal dump was an export from a bigger file in ethereal. Do you still want me to repost it in ethereal readable format?

By: Olle Johansson (oej) 2005-02-18 13:57:39.000-0600

The formatting is destroyed in the rtf file, sorry to be complaining, but all the line breaks are gone when I open it in word making it very hard to read... Can you save the SIP debug as a readable text file? I really want to check this!

Thank you for being understanding.

By: Olle Johansson (oej) 2005-02-18 14:51:39.000-0600

how old is this CVS head? Can you please give me a version?

By: Olle Johansson (oej) 2005-02-18 15:01:05.000-0600

Ok, I've read through the debug output and tried to sort out the interesting packets. I can't figure out why the other end feels busy enough to send us a 491, there's no re-invite coming in from it.

Also, I suspect you are not using current CVS head, please confirm. If not, please try with current CVS head since we changed some of the SIP logic when dealing with SIP proxies (we are more correct now). This affects situations when we deal with session boarder controllers like the jasomi.

Even though I see that we are doing the wrong thing, I would like to test your situation with latest CVS head and get a SIP debug before I look into how to solve this. Please assist me with trying this if I am right that you are not using the current version.

Thank you for your assistance in this matter.

By: ennuyeux72 (ennuyeux72) 2005-02-18 19:19:40.000-0600

Yes I'm sorry this is not the latest CVS head, it is CVS head from November 22 of last year. I'll be able to upgrade and retest on Sunday and will post the results. Thanks for moving on this issue so quickly.

About the file. Should I post a word document instead?

By: Olle Johansson (oej) 2005-02-19 03:48:40.000-0600

I would prefer a text file, really. Word keeps doing strange things with line breaks so it's very hard to read the SIP messages. Looking forward to your testing results!

By: Mark Spencer (markster) 2005-03-10 19:51:49.000-0600

Any update here?  Is this still an issue?

By: Olle Johansson (oej) 2005-03-13 19:21:21.000-0600

Still looking for an update from the reporter. Please follow-up.

By: ennuyeux72 (ennuyeux72) 2005-03-17 05:14:54.000-0600

sorry for the long delay. This is still an issue with the latest cvs.
Debug to follow

By: ennuyeux72 (ennuyeux72) 2005-03-21 03:34:39.000-0600

Ok have posted the latest trace incoming491.txt
I think the reason the other files weren't readable is cos I was using cygwin and it doesn't have a full screen terminal size.
Anyway let me know if anything else is needed.

By: Olle Johansson (oej) 2005-03-21 04:51:15.000-0600

No line breaks?

By: ennuyeux72 (ennuyeux72) 2005-03-21 04:58:19.000-0600

ok i feel really stupid now so this is what i did to make this file

1. open putty session full window
2. script -a /tmp/blabla
3. asterisk -r
4. set verbose 100000000
5. sip debug
6. reproduced problem
7. quit asterisk cli
8. ctrl d to stop write to /tmp/blabla
9. sftp blabla to windows box
10. open with notepad, remove any trade names etc.
11. posted to bugs.

Dont really know what else to do to get it in the format you want.

By: Olle Johansson (oej) 2005-03-21 05:03:51.000-0600

Seems like after the 491, we are getting a re-invite from the other side that we deny... Strange.

* I need to see the sip.conf
* Is the latest CVS head? If not, try with the latest.

By: Olle Johansson (oej) 2005-04-19 11:48:14

Waiting for response!

By: Olle Johansson (oej) 2005-05-01 15:28:57

...waiting for configuration...

If you do not provide us with information, we can't really assist you in fixing this. Will have to close this soon due to lack of interest from reporter.

By: Michael Jerris (mikej) 2005-06-27 23:19:37

A coulple months is quite a while.. Closing.  Please re-open if you can provide the requested information.