Hangup when dealing with external exchange

#1

Hello,

I’m managing an Asterisk PBX with a simple SIP setup with three terminals peered and a trunk provided by Vodafone, working as expected with the majority of external private exchanges, but having a problem with those ISDN-based I think, please see the actual call network capture on UDP port 5060 of the Debian stretch box.

The server announces the functions and audio codecs supported to the proxy counterpart:

12:17:18.414546 IP (tos 0x0, ttl 64, id 13131, offset 0, flags [none], proto UDP (17), length 963)
    46.27.XXX.XXX.5060 > 217.130.XXX.XXX.5095: [udp sum ok] SIP, length: 935
	SIP/2.0 200 OK
	Via: SIP/2.0/UDP 217.130.XXX.XXX:5095;branch=z9hG4bKgith79002gu5hgkacea0sb0000g00.1;received=217.130.XXX.XXX
	From: <sip:902XXXXXX@remote.sip.host:5095>;tag=cb32302c
	To: "lab" <sip:+34918XXXXXX@remote.sip.host:5095>;tag=as669d9e3d
	Call-ID: 1e90cd473254d7d42463452d0fd5168e@remote.sip.host
	CSeq: 1 INVITE
	Server: Vodafone-H-500-s/v3.4.20
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
	Supported: replaces, timer
	Session-Expires: 10800;refresher=uas
	Contact: <sip:+34918XXXXXX@46.27.XXX.XXX:5060>
	Content-Type: application/sdp
	Require: timer
	Content-Length: 301
	
	v=0
	o=root 521990630 521990630 IN IP4 46.27.XXX.XXX
	s=Asterisk PBX 13.14.1~dfsg-2+deb9u4
	c=IN IP4 46.27.XXX.XXX
	t=0 0
	m=audio 10162 RTP/AVP 8 0 3 101
	a=rtpmap:8 PCMA/8000
	a=rtpmap:0 PCMU/8000
	a=rtpmap:3 GSM/8000
	a=rtpmap:101 telephone-event/8000
	a=fmtp:101 0-16
	a=maxptime:150
	a=sendrecv

The proxy acknowledges

12:17:18.440061 IP (tos 0x0, ttl 125, id 0, offset 0, flags [none], proto UDP (17), length 387)
    217.130.XXX.XXX.5095 > 46.27.XXX.XXX.5060: [udp sum ok] SIP, length: 359
	ACK sip:+34918XXXXXX@46.27.XXX.XXX:5060 SIP/2.0
	Via: SIP/2.0/UDP 217.130.XXX.XXX:5095;branch=z9hG4bKf3je61001glueqrtsmm0.1
	To: "lab" <sip:+34918XXXXXX@remote.sip.host:5095>;tag=as669d9e3d
	From: <sip:902XXXXXX@remote.sip.host:5095>;tag=cb32302c
	Call-ID: 1e90cd473254d7d42463452d0fd5168e@remote.sip.host
	CSeq: 1 ACK
	Max-Forwards: 68
	Content-Length: 0

And immediately hangs up

12:17:18.446047 IP (tos 0x0, ttl 125, id 0, offset 0, flags [none], proto UDP (17), length 567)
    217.130.XXX.XXX.5095 > 46.27.XXX.XXX.5060: [udp sum ok] SIP, length: 539
	BYE sip:+34918XXXXXX@46.27.XXX.XXX:5060 SIP/2.0
	Via: SIP/2.0/UDP 217.130.XXX.XXX:5095;branch=z9hG4bKgith79002gu5hgkacea0sd0000010.1
	To: "lab" <sip:+34918XXXXXX@remote.sip.host:5095>;tag=as669d9e3d
	From: <sip:902XXXXXX@remote.sip.host:5095>;tag=cb32302c
	Call-ID: 1e90cd473254d7d42463452d0fd5168e@remote.sip.host
	CSeq: 2 BYE
	Max-Forwards: 68
	Content-Length: 0
	Reason: Q.850;cause=111
	P-Charging-Vector: icid-value=5d95ba81040bd15680d68d79fab71621
	P-Charging-Function-Addresses: ccf="aaa://mm.remote.sip.host:3868;transport=tcp"

with a Q.850 status code 111, which means Protocol error, unspecified.

This happens in the very moment when the remote exchange executes divert after a keypad option. 111 is not much explicative of the problem…

Please note that the user agent is faked. I run Asterisk version 13.14.1

I would blame the destination PBX, but a SIP VoIP connection managed directly by the Vodafone router works well against the same phones…

Thanks in advance :wink:
Jordi

#2

You have provided SIP traces but claim the problem is with ISDN!

The BYE seems to have come from the other side.

#3

Yes, it clearly comes from the other side, but I recall it worked if SIP was managed by the official provider router device… I don’t really know what kind of exchange the other side has, I will ammend the title, sorry.

#4

Only the other side may know why their system aborted the call.