[asterisk-users] SIP dialog matching problem? (1.4.23.1)
Klaus Darilion
klaus.mailinglists at pernau.at
Fri Mar 6 08:03:00 CST 2009
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 <klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>>
>
> 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: 9463D153-64F11DE-8602E9BF-A87F52E0 at 172.16.103.15
> <mailto:9463D153-64F11DE-8602E9BF-A87F52E0 at 172.16.103.15>
> > <mailto:9463D153-64F11DE-8602E9BF-A87F52E0 at 172.16.103.15
> <mailto:9463D153-64F11DE-8602E9BF-A87F52E0 at 172.16.103.15>>
> > (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
More information about the asterisk-users
mailing list