On Fri, Mar 6, 2009 at 3:03 PM, Klaus Darilion <[email protected] > wrote:
> > > Santiago Gimeno schrieb: > > Hello, > > > > Thanks for the reply. > > > > Yes, I'm using pedantic=yes. I will report this asap. > > > > One more thing that I have observed and might be also related to this > issue. > > > > 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. > > This is wrong. This is definitely a new dialog, thus dialog-ids should > change. Further, the request must not have a totag. Yes, you're right in that there must not be to-tag. In fact the INVITE doesn't have a to-tag. > > > (I think this is legal > > as stated in the RFC 3261-8.1.3.4: "/It is RECOMMENDED that the UAC > > reuse the same To, From, and Call-ID used in the original redirected > > I guess they mean the From URI and the To URI, but not the tags. 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. 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? best regards, Santi > > klaus > > > request, but the UAC MAY also choose to update the Call-ID header field > > value for new requests, for example./"). 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? > > > > Best regards, > > > > Santi > > > > 2009/3/4 Klaus Darilion <[email protected] > > <mailto:[email protected]>> > > > > Hi! > > > > Actually I would consider this as a bug, thus you should report it at > > bugs.digium.com <http://bugs.digium.com>. > > > > Are you using pedantic=yes (sip.conf)? If not, it would be > interesting > > if the pedantic mode has the same problem. > > > > regards > > klaus > > > > Santiago Gimeno schrieb: > > > Hello all, > > > > > > Not sure if this mail belongs to this users or dev list. Sorry > about > > > that. > > > > > > We have the following scenario: > > > > > > PhoneA OpenSER Asterisk PhoneB > > PhoneC > > > | | | | > > | > > > | | | | > > | > > > | | | | > > | > > > |INVITE B | | | > > | > > > |------------->| | | > > | > > > | |INVITE B | | > > | > > > | |------------->| | > > | > > > | | |INVITE B | > > | > > > | | |------------->| > > | > > > | | |486 Busy Here | > > | > > > | | |<-------------| > > | > > > | | |ACK | > > | > > > | | |------------->| > > | > > > | |486 Busy Here | | > > | > > > | |<-------------| | > > | > > > | |ACK | | > > | > > > | |------------->| | > > | > > > |302 MOVED (to C) | | > > | > > > |<-------------| | | > > | > > > |ACK | | | > > | > > > |------------->| | | > > | > > > |INVITE C | | | > > | > > > |------------->| | | > > | > > > | |INVITE C | | > > | > > > | |------------->| | > > | > > > | |503 Unavailable | > > | > > > | |<-------------| | > > | > > > | |ACK | | > > | > > > | |------------->| | > > | > > > |503 Unavailable | | > > | > > > |<-------------| | | > > | > > > |ACK | | | > > | > > > |------------->| | | > > | > > > | | | | > > | > > > | | | | > > | > > > > > > > > > > > > 1.- Phone A calls Phone B behind Asterisk. > > > 2.- Phone B rejects call by sending a '486 Busy Here' response. > > > 3.- When OpenSER receives the 486 it sends a '302 Moved > Temporarily' > > > to Phone A to redirect the call to Phone C. > > > 4.- Phone A perfoms the redirection and sends a new INVITE to > Phone C > > > (that is also behind Asterisk) with same call-id BUT DIFFERENT > > from-tag, > > > CSeq. > > > 5.- Asterisk, for some reason, considers the new INVITE to belong > > to the > > > previous call and then rejects the call with a > > > '503 Unavailable'. But it cannot be considered to belong to the > same > > > dialog because the tags are different, although the call-id is > > the same. > > > We have used pedantic checking. Could it be considered as a bug? > > > > > > Looking at the code of chan_sip.c (version 1.4.23.1), we have > > observed > > > that in function 'find_call' line 4667, asterisk is considering > > the call > > > as FOUND because of this test: > > > !ast_test_flag(&p->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED). > > > Commenting out this comparison, the call proceeds correctly. > > Sure, there > > > is some reason for this checking and we would like to know which > > is and > > > in what does it affect. How could we fix it? > > > > > > The following is the asterisk console output when the call does > not > > > proceed: > > > [Mar 2 12:15:24] DEBUG[9989]: chan_sip.c:15813 handle_request: > **** > > > Received INVITE (5) - Command in SIP INVITE [Mar 2 12:15:24] > > > NOTICE[9989]: chan_sip.c:14724 > > > handle_request_invite: Unable to create/find SIP channel for this > > INVITE > > > [Mar 2 12:15:24] DEBUG[9989]: chan_sip.c:4653 find_call: = > > Looking for > > > Call ID: [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > (Checking From) --From tag 182B3580-E9 --To-tag as62e21069 > > > > > > Any feedback would be appreciated. > > > > > > Thank you in advance, > > > > > > Santi > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > -- Bandwidth and Colocation Provided by > http://www.api-digital.com -- > > > > > > asterisk-users mailing list > > > To UNSUBSCRIBE or update options visit: > > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > _______________________________________________ > > -- Bandwidth and Colocation Provided by http://www.api-digital.com-- > > > > asterisk-users mailing list > > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > > > asterisk-users mailing list > > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-users > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
