SIP diversion header broken solution

Hello
I’m using Asterisk server like b2b and VoicemailServer, my server is connected to Asterisk server with a Trunk SIP.
When a external sip device call to another and it reject the call, an invite message goes to a particular extension to Asterisk server with Diversion and History-info headers.
To send the call goes to the right VM, I check the diversion header on the sip message and according to this I setup the right VM’s box.
The solution for this scenario was using the ${SIP_HEADER(Diversion)} function, but now Asterisk move a SIP channel to a Localchannel ( Now forwarding SIP/ XX to Local/) and this function doesn’t work in a localchannel.

I don’t want that asterisk receive the call in local because I can’t
read headers in local…
Is any way to remove this way to solve the forward ?

Regards

That would require a major rewrite of the code. However, have a search of issues.asterisk.org, as one of the recent issues was about propagating information to a (302) redirected call.

Thanks for the answer, let me check the issues to see if something there can help me.
Thanks a lot.

I was reading the issues, but it doesn’t applies to my implementation. my problem is Asterisk use localchannels to perform a invite with diversion header. With local channels I can’t detect any SIP header ( like diversion or history headers )
In some previous asterisk version (1.4.28 I think ), when you establish a “sip channel” it doesn’t was move to a “local channel” in the same transaction.

I cannot remember the exact issue, but the issue I am thinking of is also the result of using a local channel.

If we are talking about what happens when the downstream system redirects with status 302, a local channel is fundamental to how the current code handles this situation. I don’t think this will change unless someone contributes code.

If you don’t think there is a 302 involved, you need to provide the full SIP bug reporting informtion, as I think a 302 response is the only case where a local channel gets introduced by Asterisk itself.

Firts the explanation

A(sip-dkt )<–Asterisk—> Proxy(SIP-genreal)

A call B,
B start ringing
B time out expire,
Proxy send an INVITE to static extension (7000 VM extension) with Diversion header.
When asterisk receive this invite perform a “move channel sip to local”. Here is when I can’t detect the diversion header to setup the right VM.
The proxy server use the VM extension for leave (based on Diversion header) or hear the VM.

— (7 headers 0 lines) —

<— SIP read from 173.32.214.29:61338 —>
INVITE sip:101@173.32.210.17 SIP/2.0
Via: SIP/2.0/UDP 173.32.214.29:61338;branch=z9hG4bK-d8754z-944bc114b61bf551-1—d8754z-;rport
Max-Forwards: 70
Contact: sip:202@173.32.214.29:61338
To: "101"sip:101@173.32.210.17
From: “202"sip:202@173.32.210.17;tag=675da64f
Call-ID: NWNhZmUyMjNkNDU2ZDgwOTNmZDI5ZmYyZGQ1M2EzOTI.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Proxy-Authorization: Digest username=“202”,realm=“asterisk”,nonce=“2bbb7cac”,uri="sip:101@173.32.210.17”,response=“135e8523264821892b8ea06783497465”,algorithm=MD5
User-Agent: X-Lite release 1104o stamp 56125
Content-Length: 286

v=0
o=- 6 2 IN IP4 173.32.214.29
s=CounterPath X-Lite 3.0
c=IN IP4 173.32.214.29
t=0 0
m=audio 61526 RTP/AVP 0 101
a=alt:1 2 : Nz4VvAN4 ajlnuXXm 173.32.214.29 61526
a=alt:2 1 : ILwrR+Ll 9sXMXLqC 10.116.70.26 61526
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv

<------------->
— (13 headers 11 lines) —
Sending to 173.32.214.29 : 61338 (NAT)
Using INVITE request as basis request - NWNhZmUyMjNkNDU2ZDgwOTNmZDI5ZmYyZGQ1M2EzOTI.
Found user '202’
Found RTP audio format 0
Found RTP audio format 101
Found audio description format telephone-event for ID 101
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 173.32.214.29:61526
Looking for 101 in default (domain 173.32.210.17)
list_route: hop: sip:202@173.32.214.29:61338

<— Transmitting (NAT) to 173.32.214.29:61338 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 173.32.214.29:61338;branch=z9hG4bK-d8754z-944bc114b61bf551-1—d8754z-;received=173.32.214.29;rport=61338
From: "202"sip:202@173.32.210.17;tag=675da64f
To: "101"sip:101@173.32.210.17
Call-ID: NWNhZmUyMjNkNDU2ZDgwOTNmZDI5ZmYyZGQ1M2EzOTI.
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: sip:101@173.32.210.17
Content-Length: 0

<------------>
– Executing [101@default:1] Dial(“SIP/202-00000004”, “SIP/101@wsm|15”) in new stack
Audio is at 173.32.210.17 port 16870
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 173.32.210.20:5060:
INVITE sip:101@173.32.210.20:5060 SIP/2.0
Via: SIP/2.0/UDP 173.32.210.17:5060;branch=z9hG4bK6684ca42;rport
From: “DKT 202” sip:202@173.32.210.17;tag=as78843aa3
To: sip:101@173.32.210.20:5060
Contact: sip:202@173.32.210.17
Call-ID: 28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Tue, 06 Jul 2010 15:30:35 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 237

v=0
o=root 3082 3082 IN IP4 173.32.210.17
s=session
c=IN IP4 173.32.210.17
t=0 0
m=audio 16870 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv


-- Called 101@wsm

<— SIP read from 173.32.210.20:11432 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 173.32.210.17:5060;branch=z9hG4bK6684ca42;rport
From: "DKT 202"sip:202@173.32.210.17;tag=as78843aa3
To: sip:101@173.32.210.20:5060
Call-ID: 28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17
CSeq: 102 INVITE

<------------->
— (6 headers 0 lines) —

<— SIP read from 173.32.210.20:11432 —>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 173.32.210.17:5060;branch=z9hG4bK6684ca42;rport
From: "DKT 202"sip:202@173.32.210.17;tag=as78843aa3
To: sip:101@173.32.210.20:5060;tag=3ad6db
Call-ID: 28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17
CSeq: 102 INVITE
Contact: sip:101@173.32.210.45:5061
Server: Motorola/S1
Allow: INVITE,BYE,CANCEL,OPTIONS,ACK,NOTIFY,MESSAGE,REFER
Record-Route: sip:173.32.210.20:5060;lr;transport=udp
Content-Length: 0

<------------->
— (11 headers 0 lines) —
– SIP/wsm-00000005 is ringing

<— Transmitting (NAT) to 173.32.214.29:61338 —>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 173.32.214.29:61338;branch=z9hG4bK-d8754z-944bc114b61bf551-1—d8754z-;received=173.32.214.29;rport=61338
From: "202"sip:202@173.32.210.17;tag=675da64f
To: "101"sip:101@173.32.210.17;tag=as27858065
Call-ID: NWNhZmUyMjNkNDU2ZDgwOTNmZDI5ZmYyZGQ1M2EzOTI.
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: sip:101@173.32.210.17
Content-Length: 0

<------------>
sa0-asteriskCLI>
sa0-asterisk
CLI>
sa0-asteriskCLI>
sa0-asterisk
CLI>
sa0-asteriskCLI>
sa0-asterisk
CLI>
sa0-asteriskCLI>
sa0-asterisk
CLI>
sa0-asterisk*CLI>

<— SIP read from 173.32.210.20:11432 —>
INVITE sip:7000@173.32.210.17:5060 SIP/2.0
Via: SIP/2.0/UDP 173.32.210.20:5060;branch=z9hG4bK726277b7388887
Content-Type: application/sdp
From: "DKT 202"sip:202@173.32.210.17;tag=as78843aa3
Call-ID: 28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17
Supported: replaces
Contact: sip:202@173.32.210.17
Content-Length: 237
User-Agent: Asterisk PBX
CSeq: 102 INVITE
To: sip:101@173.32.210.20:5060
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO
Via: SIP/2.0/UDP 173.32.210.17:5060;branch=z9hG4bK6684ca42;rport
Date: Tue, 06 Jul 2010 15:30:35 GMT
Max-Forwards: 68
History-Info: sip:101@173.32.210.20?Reason=SIP%3Bcause%3D486;index=1,sip:7000@173.32.210.17;index=2
Diversion: sip:101@173.32.210.17;reason=user-busy

v=0
o=root 3082 3082 IN IP4 173.32.210.17
s=session
c=IN IP4 173.32.210.17
t=0 0
m=audio 16870 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<------------->
— (17 headers 12 lines) —

<— Transmitting (no NAT) to 173.32.210.20:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 173.32.210.20:5060;branch=z9hG4bK726277b7388887;received=173.32.210.20
Via: SIP/2.0/UDP 173.32.210.17:5060;branch=z9hG4bK6684ca42;rport
From: "DKT 202"sip:202@173.32.210.17;tag=as78843aa3
To: sip:101@173.32.210.20:5060
Call-ID: 28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: sip:202@173.32.210.17
Content-Length: 0

<------------>
– Now forwarding SIP/202-00000004 to ‘Local/7000@default’ (thanks to SIP/wsm-00000005)

-- Executing [7000@default:1] VoiceMailMain("Local/7000@default-1585,2", "202") in new stack

Scheduling destruction of SIP dialog ‘28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17’ in 32000 ms (Method: INVITE)
Reliably Transmitting (no NAT) to 173.32.210.20:5060:
CANCEL sip:101@173.32.210.20:5060 SIP/2.0
Via: SIP/2.0/UDP 173.32.210.17:5060;branch=z9hG4bK6684ca42;rport
From: “DKT 202” sip:202@173.32.210.17;tag=as78843aa3
To: sip:101@173.32.210.20:5060
Call-ID: 28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17
CSeq: 102 CANCEL
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0


Scheduling destruction of SIP dialog ‘28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17’ in 32000 ms (Method: INVITE)

<— SIP read from 173.32.210.20:11432 —>
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 173.32.210.20:5060;branch=z9hG4bK726277b7388887
Via: SIP/2.0/UDP 173.32.210.17:5060;branch=z9hG4bK6684ca42;rport
From: "DKT 202"sip:202@173.32.210.17;tag=as78843aa3
To: sip:101@173.32.210.20:5060;tag=3ad6db
Call-ID: 28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17
CSeq: 102 INVITE

<------------->
— (7 headers 0 lines) —
Transmitting (no NAT) to 173.32.210.20:5060:
ACK sip:101@173.32.210.20:5060 SIP/2.0
Via: SIP/2.0/UDP 173.32.210.17:5060;branch=z9hG4bK6684ca42;rport
From: “DKT 202” sip:202@173.32.210.17;tag=as78843aa3
To: sip:101@173.32.210.20:5060;tag=3ad6db
Contact: sip:202@173.32.210.17
Call-ID: 28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0


<— SIP read from 173.32.210.20:11432 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 173.32.210.17:5060;branch=z9hG4bK6684ca42;rport
From: "DKT 202"sip:202@173.32.210.17;tag=as78843aa3
To: sip:101@173.32.210.20:5060
Call-ID: 28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17
CSeq: 102 CANCEL

<------------->
— (6 headers 0 lines) —
Really destroying SIP dialog ‘28620b4b41e70f3b16e2dfde6ca28468@173.32.210.17’ Method: INVITE
– Local/7000@default-1585,1 answered SIP/202-00000004
Audio is at 173.32.210.17 port 11014
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<— Reliably Transmitting (NAT) to 173.32.214.29:61338 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 173.32.214.29:61338;branch=z9hG4bK-d8754z-944bc114b61bf551-1—d8754z-;received=173.32.214.29;rport=61338
From: "202"sip:202@173.32.210.17;tag=675da64f
To: "101"sip:101@173.32.210.17;tag=as27858065
Call-ID: NWNhZmUyMjNkNDU2ZDgwOTNmZDI5ZmYyZGQ1M2EzOTI.
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: sip:101@173.32.210.17
Content-Type: application/sdp
Content-Length: 213

v=0
o=root 3082 3082 IN IP4 173.32.210.17
s=session
c=IN IP4 173.32.210.17
t=0 0
m=audio 11014 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<------------>

<— SIP read from 173.32.214.29:61338 —>
ACK sip:101@173.32.210.17 SIP/2.0
Via: SIP/2.0/UDP 173.32.214.29:61338;branch=z9hG4bK-d8754z-3f671262b6323a06-1—d8754z-;rport
Max-Forwards: 70
Contact: sip:202@173.32.214.29:61338
To: "101"sip:101@173.32.210.17;tag=as27858065
From: “202"sip:202@173.32.210.17;tag=675da64f
Call-ID: NWNhZmUyMjNkNDU2ZDgwOTNmZDI5ZmYyZGQ1M2EzOTI.
CSeq: 2 ACK
Proxy-Authorization: Digest username=“202”,realm=“asterisk”,nonce=“2bbb7cac”,uri="sip:101@173.32.210.17”,response=“135e8523264821892b8ea06783497465”,algorithm=MD5
User-Agent: X-Lite release 1104o stamp 56125
Content-Length: 0

<------------->
— (11 headers 0 lines) —
– <Local/7000@default-1585,2> Playing ‘vm-password’ (language ‘en’)

<— SIP read from 173.32.214.29:61338 —>
BYE sip:101@173.32.210.17 SIP/2.0
Via: SIP/2.0/UDP 173.32.214.29:61338;branch=z9hG4bK-d8754z-ea027238241cb779-1—d8754z-;rport
Max-Forwards: 70
Contact: sip:202@173.32.214.29:61338
To: "101"sip:101@173.32.210.17;tag=as27858065
From: “202"sip:202@173.32.210.17;tag=675da64f
Call-ID: NWNhZmUyMjNkNDU2ZDgwOTNmZDI5ZmYyZGQ1M2EzOTI.
CSeq: 3 BYE
Proxy-Authorization: Digest username=“202”,realm=“asterisk”,nonce=“2bbb7cac”,uri="sip:101@173.32.210.17”,response=“18559c374b251a457f4248eb7d0a13e4”,algorithm=MD5
User-Agent: X-Lite release 1104o stamp 56125
Reason: SIP;description="User Hung Up"
Content-Length: 0

<------------->
— (12 headers 0 lines) —
Sending to 173.32.214.29 : 61338 (NAT)

<— Transmitting (NAT) to 173.32.214.29:61338 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 173.32.214.29:61338;branch=z9hG4bK-d8754z-ea027238241cb779-1—d8754z-;received=173.32.214.29;rport=61338
From: "202"sip:202@173.32.210.17;tag=675da64f
To: "101"sip:101@173.32.210.17;tag=as27858065
Call-ID: NWNhZmUyMjNkNDU2ZDgwOTNmZDI5ZmYyZGQ1M2EzOTI.
CSeq: 3 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

<------------>
– Executing [h@default:1] Hangup(“SIP/202-00000004”, “”) in new stack
== Spawn h extension (default, h, 1) exited non-zero on ‘SIP/202-00000004’
[Jul 6 11:30:47] WARNING[13524]: app_voicemail.c:7440 vm_authenticate: Unable to read password
– Executing [h@default:1] Hangup(“Local/7000@default-1585,2”, “”) in new stack
== Spawn extension (default, h, 1) exited non-zero on ‘Local/7000@default-1585,2’
== Spawn extension (default, 101, 1) exited non-zero on ‘SIP/202-00000004’
– Executing [h@default:1] Hangup(“SIP/202-00000004”, “”) in new stack
== Spawn extension (default, h, 1) exited non-zero on 'SIP/202-00000004’
Really destroying SIP dialog ‘NWNhZmUyMjNkNDU2ZDgwOTNmZDI5ZmYyZGQ1M2EzOTI.’ Method: BYE

<— SIP read from 173.32.214.29:61338 —>

<------------->
Really destroying SIP dialog ‘ZGM5Y2JlMDE1NTIzYTJjMTlhYWZiZGVmY2UwYmY1ODE.’ Method: ACK
sa0-asterisk*CLI>

That looks broken to me. As I understand it, Diversion is for information only, i.e. I don’t think it should do anything except update the call meta-data.

It looks like Diversion is only a draft, but that hasn’t stopped other SIP features.

I’m not sure that you’ve actually said which version you are using.

I wonder if this is really the Asterisk doesn’t understand multiple branches with the same call id issue (I haven’t looked to see if they are the same).

Asterisk is working fine regarding to the multiple branches in the same call id. The problem is because Asterisk when receive this new invite move the SIP channel to a Local channel
Line
– Now forwarding SIP/202-00000004 to ‘Local/7000@default’ (thanks to SIP/wsm-00000005)
In my extension when came an INVITE to 7000 extension I move this call to VM

exten => 7000,1,Set(Who=${SIP_HEADER(Diversion)})
exten => 7000,2,NoOp(${Whox})
exten => 7000,n,GotoIf($["${Who}" = “”]?s-earVM|1:s-liveVM|1)

exten => s-earVM,1,VoicemailMain(${CALLERID(num)})
exten => 7000,1,VoicemailMain(${CALLERID(num)})
exten => s-liveVM,1,Set(Cause=${SIP_HEADER(Diversion)})
exten => s-liveVM,n,Set(Cause=${CUT(Cause,=,2)})
exten => s-liveVM,n,Voicemail(${CALLERID(rdnis)})

How Asterisk now use the localchannel, I can’t use the ${SIP_HEADER(Diversion)} to detect the Diversion header and setup the right VM box.

I hope so that this give you more information about the issue.

You keep repeating yourself. If you think I am misunderstanding, you need to work out what my misunderstanding is, rather than repeating the original statements. It can be difficult if you are using a second language, but writing too much tends to be the best approach then.

The question is why is it using the Diversion header in this way. As far as I can see the invite should be handled as a normal invite, as far as call routing is concerned, but it looks like it is being handled like a status 302 response, which is completely different.

At the moment, I think you need to raise an issue on issues.asterisk.org, but you will need to:

  • specify the exact version of Asterisk that you are using, and be sure that it is supported and recent;
  • specify how to recreate the problem - ideally without using any special equipment, but otherwise you need to specify, in as much detail as possible, what is at the other end of the trunk and how it is configured (people don’t like creating custom test harnesses);
  • specify exactly how Asterisk should have handled the problem invite;
  • clearly state how the actually behaviour differs;
  • as far as possible make sure that this is not related to a known problem.

I asked you for the version, but you didn’t give it;

I think you need to step back a bit and be clearer about what should happen, and what is actually happening. What I think you are trying to say is that the invite should have been treated as a completely new invite, as if for an unrelated call, and should have set the Divert header information.

What seems to be happening, is that some call is being redirected, in the same way as if it had received a 302 response, but I’m not clear which call that is.

I suppose I could find out if I looked hard enough, but this is a peer support group, not a contracted support channel, and even when you go to issues.asterisk.org, there is no contractual commitment to fix the problem or provide a workround, so the more clearly you highlight all the details of the evidence, the more likely you are to get a quick fix.

The reason I suggested there may be a problem with branches is that I cannot think why Asterisk would connect the incoming INVITE with any existing call.

I don’t think that this looked like a re-invite, and, whilst I suppose there may be some obscure way of using Diversion on re-invites to initiate forwarding, it would be a rather unusual usage. However, if that is the case, the current Asterisk design would use a local channel to implement the forwarding, because it needs the local channel to interpret the directory number. If you are aware of any such use of DIversion, you need to explain why it is not being used in that way here.

this is the answer that I’m looking for

" However, if that is the case, the current Asterisk design would use a local channel to implement the forwarding, because it needs the local channel to interpret the directory number. If you are aware of any such use of DIversion, you need to explain why it is not being used in that way here."

I’m using 1.4.33 Asterisk version, my problem is how Asterisk resolve the call forward with local channels. I need identify if and INVITE has or not Diversion header, when this INVITE is coming from a already created session ( as I explained you in the example) I can’t detect this header because this channel is not anymore a sip channel and now is a localchannel.
May be the solution is can setup a variable ( Diversion header ) in a local channel.

Asterisk is using a local channel because it is actually trying to DO a transfer, not just be the receiving end of a transferred call. If you’ve produced a complete SIP trace I can see no reason why it should be trying to transfer a call.