<br><div class="gmail_quote">On Fri, Mar 6, 2009 at 3:03 PM, Klaus Darilion <span dir="ltr"><<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Santiago Gimeno schrieb:<br>
<div class="im">> 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,<br>
> but in this case, the SIP Phone that receives the 302 generates a new<br>
> INVITE to the "new" address with exactly the same dialog information as<br>
> the initial INVITE: call-id, from-tag and to-tag.<br>
<br>
</div>This is wrong. This is definitely a new dialog, thus dialog-ids should<br>
change. Further, the request must not have a totag.</blockquote><div><br>Yes, you're right in that there must not be to-tag. In fact the INVITE doesn't have a to-tag. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="im"><br>
(I think this is legal<br>
> as stated in the RFC 3261-8.1.3.4: "/It is RECOMMENDED that the UAC<br>
> reuse the same To, From, and Call-ID used in the original redirected<br>
<br>
</div>I guess they mean the From URI and the To URI, but not the tags.</blockquote><div><br>I'm not sure about that. If you look at RFC 3665-3.6, there is a simple example of a call redirection in which the 2nd INVITE has the same Call-ID and from-tag but the CSeq numbers are different.<br>
<br>The question is: should Asterisk reject the 2nd INVITE for having the same dialog id (call-id and from-tag) as the 1st INVITE even though that dialog is alreade in the TERMINATED state?<br><br>best regards,<br><br>Santi<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
klaus<br>
<div class="im"><br>
> request, but the UAC MAY also choose to update the Call-ID header field<br>
> value for new requests, for example./"). Asterisk answers to this INVITE<br>
> with a 503 Unavailable because it matches with the previous dialog. I'm<br>
> not sure if this is how Asterisk should behave, or it should allow the<br>
> call to progress as the previous dialog is already in the TERMINATED<br>
> state. What do you think?<br>
><br>
> Best regards,<br>
><br>
> Santi<br>
><br>
> 2009/3/4 Klaus Darilion <<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</a><br>
</div>> <mailto:<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</a>>><br>
<div class="im">><br>
> Hi!<br>
><br>
> Actually I would consider this as a bug, thus you should report it at<br>
</div>> <a href="http://bugs.digium.com" target="_blank">bugs.digium.com</a> <<a href="http://bugs.digium.com" target="_blank">http://bugs.digium.com</a>>.<br>
<div><div></div><div class="h5">><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>
> > 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<br>
> PhoneC<br>
> > | | | |<br>
> |<br>
> > | | | |<br>
> |<br>
> > | | | |<br>
> |<br>
> > |INVITE B | | |<br>
> |<br>
> > |------------->| | |<br>
> |<br>
> > | |INVITE B | |<br>
> |<br>
> > | |------------->| |<br>
> |<br>
> > | | |INVITE B |<br>
> |<br>
> > | | |------------->|<br>
> |<br>
> > | | |486 Busy Here |<br>
> |<br>
> > | | |<-------------|<br>
> |<br>
> > | | |ACK |<br>
> |<br>
> > | | |------------->|<br>
> |<br>
> > | |486 Busy Here | |<br>
> |<br>
> > | |<-------------| |<br>
> |<br>
> > | |ACK | |<br>
> |<br>
> > | |------------->| |<br>
> |<br>
> > |302 MOVED (to C) | |<br>
> |<br>
> > |<-------------| | |<br>
> |<br>
> > |ACK | | |<br>
> |<br>
> > |------------->| | |<br>
> |<br>
> > |INVITE C | | |<br>
> |<br>
> > |------------->| | |<br>
> |<br>
> > | |INVITE C | |<br>
> |<br>
> > | |------------->| |<br>
> |<br>
> > | |503 Unavailable |<br>
> |<br>
> > | |<-------------| |<br>
> |<br>
> > | |ACK | |<br>
> |<br>
> > | |------------->| |<br>
> |<br>
> > |503 Unavailable | |<br>
> |<br>
> > |<-------------| | |<br>
> |<br>
> > |ACK | | |<br>
> |<br>
> > |------------->| | |<br>
> |<br>
> > | | | |<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<br>
> from-tag,<br>
> > CSeq.<br>
> > 5.- Asterisk, for some reason, considers the new INVITE to belong<br>
> 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<br>
> 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<br>
> observed<br>
> > that in function 'find_call' line 4667, asterisk is considering<br>
> 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.<br>
> Sure, there<br>
> > is some reason for this checking and we would like to know which<br>
> 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<br>
> INVITE<br>
> > [Mar 2 12:15:24] DEBUG[9989]: chan_sip.c:4653 find_call: =<br>
> 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>
> <mailto:<a href="mailto:9463D153-64F11DE-8602E9BF-A87F52E0@172.16.103.15">9463D153-64F11DE-8602E9BF-A87F52E0@172.16.103.15</a>><br>
> > <mailto:<a href="mailto:9463D153-64F11DE-8602E9BF-A87F52E0@172.16.103.15">9463D153-64F11DE-8602E9BF-A87F52E0@172.16.103.15</a><br>
> <mailto:<a href="mailto:9463D153-64F11DE-8602E9BF-A87F52E0@172.16.103.15">9463D153-64F11DE-8602E9BF-A87F52E0@172.16.103.15</a>>><br>
> > (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>
> ><br>
> ------------------------------------------------------------------------<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>
><br>
><br>
><br>
> ------------------------------------------------------------------------<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>
</div></div></blockquote></div><br>