[asterisk-users] SIP dialog matching problem? (1.4.23.1)
Santiago Gimeno
santiago.gimeno at gmail.com
Fri Mar 6 12:03:47 CST 2009
On Fri, Mar 6, 2009 at 3:03 PM, Klaus Darilion <klaus.mailinglists at pernau.at
> 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 <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
>
> _______________________________________________
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090306/0781da1b/attachment.htm
More information about the asterisk-users
mailing list