|Summary:||ASTERISK-10081: Maximum retries for seqno 102 when re-inviting.|
|Reporter:||Edwin Groothuis (mavetju)||Labels:|
|Date Opened:||2007-08-14 07:36:16||Date Closed:||2007-08-19 19:51:23|
|Environment:||Attachments:||( 0) softswitch-two.txt|
|Description:||We have a provider with two softswitches. Number one which contacts us, and number two which goes via number one to us.|
If a call comes through from the first softswitch (directly from number one to us), a call gets setup properly and we have a proper working RTP stream.
If a call comes through from the second softswitch (going through the first one, and then to us), the call gets setup, we hear one second of the RTP stream and then the call drops out.
I will attach a file with the output of "sip debug"
- softswitch-two.txt (not working)
At line 366, you see a re-invite with CSeq 102. And then retransmits of them in a fast tempo till asterisk gives up.
I personally think that it shouldn't be 102 because 103 has already been shown.
****** ADDITIONAL INFORMATION ******
|Comments:||By: Edwin Groothuis (mavetju) 2007-08-14 07:54:26|
ps. Setting "canreinvite=no" overcomes the problem, but then the RTP traffic goes via the asterisk box instead of directly to the destination machine.
By: Mark Michelson (mmichelson) 2007-08-14 09:47:43
This seems similar to issue ASTERISK-9933, except there's no T.38 involved here. In that issue, there were two Asterisk boxes in between two ATA's and they exhibited the same behavior on re-invites.
Are both Asterisk boxes running 1.4 with an SVN checkout later than revision 77824? If softswitch-one is not, then it is not sending the 100 Trying message it should be sending to softswitch-two which is why it continues retransmitting the re-invites.
By: Edwin Groothuis (mavetju) 2007-08-14 17:58:59
The softswitch is not an asterisk based device, the brand is Entite.
Our Asterisk box is running the 1.4 branch, revision 78907.
(It worked fine with Asterisk 1.2)
By: Edwin Groothuis (mavetju) 2007-08-18 08:12:14
This issue is better described/determined at http://bugs.digium.com/view.php?id=10481. Please close this one.