Hello,<br><br>Thanks for the reply.<br><br>Yes, I'm using pedantic=yes. I will report this asap.<br><br>One more thing that I have observed and might be also related to this issue.<br><br>The scenario is the same as the one I described in the previous mail, but in this case, the SIP Phone that receives the 302 generates a new INVITE to the "new" address with exactly the same dialog information as the initial INVITE: call-id, from-tag and to-tag. (I think this is legal as stated in the RFC 3261-8.1.3.4: "<i>It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example.</i>"). Asterisk answers to this INVITE with a 503 Unavailable because it matches with the previous dialog. I'm not sure if this is how Asterisk should behave, or it should allow the call to progress as the previous dialog is already in the TERMINATED state. What do you think?<br>
<br>Best regards,<br><br>Santi<br><br><div class="gmail_quote">2009/3/4 Klaus Darilion <span dir="ltr"><<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi!<br>
<br>
Actually I would consider this as a bug, thus you should report it at<br>
<a href="http://bugs.digium.com" target="_blank">bugs.digium.com</a>.<br>
<br>
Are you using pedantic=yes (sip.conf)? If not, it would be interesting<br>
if the pedantic mode has the same problem.<br>
<br>
regards<br>
klaus<br>
<br>
Santiago Gimeno schrieb:<br>
<div><div></div><div class="h5">> Hello all,<br>
><br>
> Not sure if this mail belongs to this users or dev list. Sorry about<br>
> that.<br>
><br>
> We have the following scenario:<br>
><br>
> PhoneA OpenSER Asterisk PhoneB PhoneC<br>
> | | | | |<br>
> | | | | |<br>
> | | | | |<br>
> |INVITE B | | | |<br>
> |------------->| | | |<br>
> | |INVITE B | | |<br>
> | |------------->| | |<br>
> | | |INVITE B | |<br>
> | | |------------->| |<br>
> | | |486 Busy Here | |<br>
> | | |<-------------| |<br>
> | | |ACK | |<br>
> | | |------------->| |<br>
> | |486 Busy Here | | |<br>
> | |<-------------| | |<br>
> | |ACK | | |<br>
> | |------------->| | |<br>
> |302 MOVED (to C) | | |<br>
> |<-------------| | | |<br>
> |ACK | | | |<br>
> |------------->| | | |<br>
> |INVITE C | | | |<br>
> |------------->| | | |<br>
> | |INVITE C | | |<br>
> | |------------->| | |<br>
> | |503 Unavailable | |<br>
> | |<-------------| | |<br>
> | |ACK | | |<br>
> | |------------->| | |<br>
> |503 Unavailable | | |<br>
> |<-------------| | | |<br>
> |ACK | | | |<br>
> |------------->| | | |<br>
> | | | | |<br>
> | | | | |<br>
><br>
><br>
><br>
> 1.- Phone A calls Phone B behind Asterisk.<br>
> 2.- Phone B rejects call by sending a '486 Busy Here' response.<br>
> 3.- When OpenSER receives the 486 it sends a '302 Moved Temporarily'<br>
> to Phone A to redirect the call to Phone C.<br>
> 4.- Phone A perfoms the redirection and sends a new INVITE to Phone C<br>
> (that is also behind Asterisk) with same call-id BUT DIFFERENT from-tag,<br>
> CSeq.<br>
> 5.- Asterisk, for some reason, considers the new INVITE to belong to the<br>
> previous call and then rejects the call with a<br>
> '503 Unavailable'. But it cannot be considered to belong to the same<br>
> dialog because the tags are different, although the call-id is the same.<br>
> We have used pedantic checking. Could it be considered as a bug?<br>
><br>
> Looking at the code of chan_sip.c (version 1.4.23.1), we have observed<br>
> that in function 'find_call' line 4667, asterisk is considering the call<br>
> as FOUND because of this test:<br>
> !ast_test_flag(&p->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED).<br>
> Commenting out this comparison, the call proceeds correctly. Sure, there<br>
> is some reason for this checking and we would like to know which is and<br>
> in what does it affect. How could we fix it?<br>
><br>
> The following is the asterisk console output when the call does not<br>
> proceed:<br>
> [Mar 2 12:15:24] DEBUG[9989]: chan_sip.c:15813 handle_request: ****<br>
> Received INVITE (5) - Command in SIP INVITE [Mar 2 12:15:24]<br>
> NOTICE[9989]: chan_sip.c:14724<br>
> handle_request_invite: Unable to create/find SIP channel for this INVITE<br>
> [Mar 2 12:15:24] DEBUG[9989]: chan_sip.c:4653 find_call: = Looking for<br>
> Call ID: <a href="mailto:9463D153-64F11DE-8602E9BF-A87F52E0@172.16.103.15">9463D153-64F11DE-8602E9BF-A87F52E0@172.16.103.15</a><br>
</div></div>> <mailto:<a href="mailto:9463D153-64F11DE-8602E9BF-A87F52E0@172.16.103.15">9463D153-64F11DE-8602E9BF-A87F52E0@172.16.103.15</a>><br>
<div class="im">> (Checking From) --From tag 182B3580-E9 --To-tag as62e21069<br>
><br>
> Any feedback would be appreciated.<br>
><br>
> Thank you in advance,<br>
><br>
> Santi<br>
><br>
><br>
</div>> ------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
><br>
> asterisk-users mailing list<br>
> To UNSUBSCRIBE or update options visit:<br>
> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
<br>
_______________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</blockquote></div><br>