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. (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. 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
