Rejecting OR Hangup doesnt work with trunk

Asterisk Asterisk SIP
#1

Hey guys , need some help here

I have an indoor station => IP 192.168.0.71
I have an proxy configured to register on indoor station (opensips PBX) with ip 192.168.0.17 port 5060
I have an asteriks with inboud trunk on same host that register on that PBX ip 192.168.0.17 port 5050
i have a softphone client where i receive the call 0.168
SO on incoming call flow go grom 0.71 => 0.17:5060 => to inbound trunk on asteriks running on 0.17:5050

all is working fine…

except the decline or hangup doesnt work, any idea what i can do?
here you see the flow on hangup

The BYE is ok from softphone to asterisk:

image
image1257×283 22.2 KB

Then BYE is ok from asteriks to opensips, but nothing happens, no hangup is done, the call is still open

image
image1358×499 26.2 KB

Same flow for decline, but here i see a 503 service not avaible from asterisk to opensips

image
image1402×290 23.5 KB

image
image1639×419 29.1 KB

what could be wrong? dont think its an issue with opensips

If i leave out asterisk , and register my softphone as a trunk for inbound from opensips, then i can do decline and hangup … if i move asteriks between , then i have the issue…

trunk setup:

[mytrunk]
type=registration
outbound_auth=mytrunk
server_uri=sip:192.168.0.17
client_uri=sip:10000000005@192.168.0.17
retry_interval=30
 
[mytrunk]
type=auth
auth_type=userpass
password=XXX
username=10000000005
 
[mytrunk]
type=aor
contact=sip:192.168.0.17:5060
;qualify_frequency=300
 
[mytrunk]
type=endpoint
context=default
disallow=all
allow=ulaw,alaw
allow=h264
outbound_auth=mytrunk
aors=mytrunk
 
[mytrunk]
type=identify
endpoint=mytrunk
match=192.168.0.17

and a verry easy dialplan to test:

exten => s,1,Set(DIALGROUP(mygroup,add)=PJSIP/6001)
exten => s,n,Dial(${DIALGROUP(mygroup)},60)
#2

Does that mean that you you have two processes on the same machine listening to the same port?

#3

No, different port

Proxy is 5060 , asterisk is 5050, all works perfect, except hangup or decline

#4

5050 ≠ 5060 although I think it would have helped if the OP had highlighted that, as I had to look twice.

#5

Yeah, sorry about that :slight_smile:

Any clue?

#6

You’re right, the ports differ, my bad. You probably need to look at complete SIP traces to find the problem. You also haven’t posted the complete pjsip configuration.

The other thing one could check is to test the direct connection between door station and Asterisk. If that works one would at least know what to look for with the more complicated setup.

#7

Yeah, that’s the issue , I can’t use asterisk, I need opensips between , because I need to send an XML in the sip headers when registering…

Asteriks can’t do that…

I will make full sip traces later…

The pjsip info I posted is complete , I have nothing more, except for transport , where I define 5050 and some localnet networks

#8

A typo in the transport section, or so, would be bad. Since you are using opensips, you could also check kamailio. Maybe the subtle differences show something.

#9

hey, i was able to make some logs
here is transport section btw:

[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0:5050
local_net=192.168.0.0/24
local_net=10.8.0.0/24
external_media_address=xxx.com
external_signaling_address=xxx.com

Here are logs , when i dont use asteriks, so just register a softphone on opensips , then it works for both decline and hangup

when i start asterisk, and register the trunk for inbound calling, and then send it to extension
hangup and decline are not working:

you also notice in last log, when i do a hangup on softphone, it stays “INCALL” , seems the bye message doesnt work

thnx for investigating!!! if you can get this fixed, i’m willing to donate!!

#10

ExoSIP has failed to return a final response to Asterisk, for a Re-INVITE. Asterisk cannot start a BYE transaction until the re_INVITE completes. If you left it long enough, Asterisk would abort the call because of the lack of response. (Actually, as there has been an interim response, the timer may have been stopped.)

You must send a final response to a Re-INVITE, even if it is a rejection because you are unable to honour it.

#11

Hmm ok, I think I can follow, but how can I do that? :+)

Is this a setting on asterisk? Or where do I need to look??

Thnx

#12

Also an idea what’s wrong with the decline?

#13

Also , not related, to the issue I posted, but you can see also h264 video, the doorstation sends video, but I dont see it on the softphone, do you see why?

#14

It’s a fault on eXosip/3.6.0 that it is failing to handle the Re-INVITE legally.

Asterisk appears to he Re-INVITEing in order to delete the video stream.

#15

The first problem is that there is nothing left to decline as Asterisk has already rejected the incoming leg with 503 Service Unavailable.

I don’t know how your extension s is reached, so I don’t know how the outgoing leg from Asterisk has been initiated after the incoming one has already failed.

#16

ok, il will have a look on opensips/exosip side

what do you mean by that? asterisk deletes the video? or why dont i see video?
also if i leave out, asteriks, the log file “opensips-hangup.txt” , there i accept the call, without asteriks, only opensips, but i dont see the h264 video either? allthough i see it in the invite? or what am i missing?

#17

The request to Asterisk contains:

m=video 9654 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42801F;packetization-mode=1
a=recvonly

Which says the caller wants to receive an H.264 video stream, but will not send one.

Asterisk’s initial response is:

m=video 18508 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=42801F
a=sendonly

Which is agreeing to send the stream.

However, it then re-INVITEs:

m=video 0 RTP/AVP 96

which rejects that video stream.

I don’t know why it does that, given that it then offers to send video in H.264, or VP8 to 6001:

m=video 13082 RTP/AVP 99 100
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=1;profile-level-id=42801F
a=rtpmap:100 VP8/90000
a=sendonly
#18

thats strange, its the caller that needs to send, the caller in this case is the outdoor intercom
this device : sip:10010100000@192.168.0.71

#19

eXosip/3.6.0 is definitely sending the stream as receive only.

Asterisk is ending up setting up to send video both ways, but with no means of getting the video.

Maybe some other devices don’t actually look a the a=recvonly properly, and accept video anyway.

#20

ah ok, strange

thnx for looking into it!