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-0600	Date Closed:	2011-06-07 14:10:23
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
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: PSTN--->ASTERISK--->SER--->JASOMI PEERPOINT--->SIP-UA(nat) 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. *sigh* 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.