Weird asterisk behavior

[mikealmandeel]

Hi guys. After all the help you guys have given me, I was able to get calls to connect. However, there are some issues. If you look at the enclosed pcap, you will notice some weird behavior coming from asterisk:
‘1’ - 192.168.200.1
‘7007’ - 192.168.200.111
asterisk - 192.168.200.254

-we send an invite from ‘1’ to ‘7007’ (#5)

• asterisk sends ‘1’ an ok (#15)… from here, things get weird
• asterisk originates and sends ‘7007’ another invite… why? (#16)
• ‘1’ acks the ok from the first invite (#20)
• asterisk now originates and sends an invite to ‘1’ from ‘7007’… why? (#21)
• ‘7007’ hangs up, but asterisk does not forward the bye to ‘1’… why? (#256)

im guessing maybe the bye that was sent from ‘7007’ is referring to a different session and thats why it wasn’t forwarded?

pjsip.conf:

[7007]
type = endpoint
context = internal
allow = all
aors = 7007
auth = auth7007
;dtmf_mode = rfc2833

[7007]
type = aor
max_contacts = 1

[7007]
type = identify
match = 192.168.200.111

[auth7007]
type=auth
auth_type=userpass
password=7007
username=7007

[4008]
type = endpoint
context = internal
allow = all
aors = 4008
;dtmf_mode = rfc2833

[4008]
type = aor
contact = sip:4008@192.168.200.1:5060

[4008]
type = identify
match = 192.168.200.1

[1]
type = endpoint
context = internal
allow = all
aors = 1
;dtmf_mode = rfc2833

[1]
type = aor
contact = sip:1@192.168.200.1:5060

[1]
type = identify
match = 192.168.200.1

[4010]
type = endpoint
context = internal
allow = all
aors = 4010
;dtmf_mode = rfc2833

[4010]
type = aor
contact = sip:4010@192.168.200.1:5060

[4010]
type = identify
match = 192.168.200.1

extensions.conf:

[internal]
exten=>_4008,1,Dial(PJSIP/${EXTEN})
exten=>_1,1,Dial(PJSIP/${EXTEN})
exten=>_4010,1,Dial(PJSIP/${EXTEN})
exten=>_7007,1,Dial(PJSIP/${EXTEN})

weird_behavior.zip (93.0 KB)

[jcolp]

They are in-dialog re-INVITEs to have media go directly, as you did not set “direct_media” to “no” in the endpoints.

As for the call not hanging up, the BYE request is incorrect in some way resulting in PJSIP not being able to associate it to an active session. An Asterisk log at debug level may provide insight, otherwise it’s looking at things and trying to identify it yourself.

[david551]

The Contact header is wrong, in the response to the re-INVITE. It should refer to 192.168.200.1.

Frame 25: 666 bytes on wire (5328 bits), 666 bytes captured (5328 bits) on interface enp0s25, id 0
Ethernet II, Src: Harris_dc:03:1d (00:00:c3:dc:03:1d), Dst: Dell_25:b4:47 (b8:ac:6f:25:b4:47)
Internet Protocol Version 4, Src: 192.168.200.1, Dst: 192.168.200.254
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (200)
    Status-Line: SIP/2.0 200 Ok
    Message Header
        Via: SIP/2.0/UDP 192.168.200.254:5060;branch=z9hG4bKPj1c4c7a74-d477-46af-babd-0358b6477f3d
        From: "7007" <sip:7007@192.168.200.254>;tag=c858f268-cb82-426b-84a8-8f6d693f6be7
        To: "1" <sip:1@192.168.200.1>;tag=8aM3rIBV0Z
        Call-ID: 1058682382@192.168.200.1
        [Generated Call-ID: 1058682382@192.168.200.1]
        CSeq: 32064 INVITE
        Contact: <sip:192.168.200.254>
        Allow: INVITE,ACK,CANCEL,OPTIONS,BYE
        Content-Type: application/sdp
        Content-Length: 207
    Message Body

Also there has been no ACK from Asterisk, probably because it objected to sending it to itself, so I don’t think the peer is allowed to start a BYE transaction.

[david551]

There is another protocol violation by “1”. The From tag in the INVITE must not b the same as in the preceding OPTIONS, but it is!