[asterisk-users] SIP dialog matching problem? (1.4.23.1)
Santiago Gimeno
santiago.gimeno at gmail.com
Wed Mar 4 03:12:15 CST 2009
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. (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 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>
> Hi!
>
> Actually I would consider this as a bug, thus you should report it at
> 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>
> > (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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090304/de734cbe/attachment.htm
More information about the asterisk-users
mailing list