Problem in displaying callerid when transferring a call to a sip trunk

[infalex2xl]

Good afternoon, colleagues, I ask for help.
There is a sip-trunk hipath 4000v8 <-> Asterisk (pjsip)
For example, if subscriber 1111 (hipath) calls another subscriber 2222 (hipath), then subscriber 2222 (hipath) transfers the call to subscriber 7777 (Asterisk), then subscriber 7777 will see the number 2222 on the display, and when he picks up the phone, then nothing will change. Those. subscriber 7777 is talking to subscriber 1111, but 2222 is displayed.
I watched sip packets on Asterisk (there is no information anywhere about the subscriber 1111, everywhere only 2222)
I watched packets on unify using wireshark sip and there is the same situation, when calling, only the subscriber who transferred the call appears, and the information is not updated.
The same situation is with call interceptions.

Accordingly, I suspect that Hipath does not transmit this information about the number 1111, and, perhaps, the matter is in some parameter, but I don’t know which way to dig.

Maybe someone came across something similar, someone has sip trunks with other PBXs, how are things going there?

 

[Moriendi]

I would expect an update message on in-dialog invite from the 4K to Asterisk at the moment of transfer, containing the new details. What's in the COT of the 4K trunk?

 

[infalex2xl]

hello, here is this COT on the trunk:

[pre] COT: 25 INFO: COT FOR PBX
DEVICE: INDEP SOURCE: DB
PARAMETER:
PRIORITY FOR AC WILL BE DETERMINED FROM MESSAGE PRI
TRUNK SIGNALING ANSWER ANS
KNOCKING OVERRIDE POSSIBLE KNOR
CALL EXTEND FOR BUSY, RING OR CALL STATE CEBC
NETWORKWIDE AUTOMATIC CALLBACK ON BUSY CBBN
NETWORKWIDE AUTOMATIC CALLBACK ON FREE CBFN
NETWORKWIDE CALL FORWARDING PERMITTED FWDN
NETWORKWIDE FORWARDING NO-ANSWER FNAN
DON'T RELEASE CALL TO BUSY HUNT GROUP BSHT
END-OF-DIAL FOR BLOCK IS SET BLOC
ACTIVATE TRANSIT COUNTER ADMINISTRATION FOR S0/S2 LINE ATRS
CONNECTION TO ROUTE OPTIMIZATION NODE ROPT
TSC-SIGNALING FOR NETWORKWIDE FEATURES (MANDATORY) TSCS
TRUNK SENDS CALL CHARGES TO ORIGINATING NODE NUMBER TRSC
CALL FORWARDING PROGRAMING FOR OTHER SUBSCRIBERS CFOS
PIN NETWORKWIDE POSSIBLE PINR
AOC PER CALL (AUTOMATICAL OR ON REQUEST), MAND. CORNET-NQ AOCC
LINE WITH IMPLICIT NUMBERS LINO
B-CHANNEL NEGOTIATION (PREV. PREFERRED-PREFERRED COLLISION) BCNE
NO TONE NTON[/pre]

And COS:

[pre] +------+-----------------+---------------+-----------------+
| COS | VOICE | FAX | DTE |
+------+-----------------+---------------+-----------------+
| 25 |>COS FOR PBX |
| | TA | NOCO | NOCO |
| | TNOTCR | NOTIE | NOTIE |
| | MB | | |
| | CFNR | | |
| | FWDNWK | | |
| | TTT | | |
| | FWDFAS | | |
| | CFSWF | | |
| | FWDECA | | |
| | FWDEXT | | |
+------+-----------------+---------------+-----------------+[/pre]

 

[Moriendi]

That looks OK. I was looking for NOCT which would suppress call transfer information. But it’s not there.

I think on a SIP trace you should see this information. Maybe Asterisk is ignoring it.

 

[infalex2xl]

it turned out that I was a little wrong, in the log on siemens in the invite package, I saw the missing number, here is the situation and screenshots again.
In this example, number 5073 calls to 5070 (both of these numbers are on the same gateway 102.211), then number 5070 transfers the call to number 5075 (number on Asterisk) (transfer goes through the sip gateway to siemens 102.114 via sip trunk to Asterisk on address 102.230)
After going off-hook, the display on the 5075 phone shows 5070, although I expect it should show 5073.

So, in the invite package in tcpdump sip of the gateway on siemens, I saw the number 5073, but in tcpdump on Asterisk I don’t see this number anywhere.

Perhaps, after all, Asterisk really ignores or this sip packet with the number 5073 does not reach it, while it is still unclear which way to dig.

5070 calling 5073:

Then 5070 transfers the call to number 5075 and after the answer, I see an invite packet with a mention of the number 5073

the log on asterisk looks like this, there is no mention of the number 5073

 

[Moriendi]

If 2222 calls 7777 and hangs up before 7777 answers to make the transfer, 4K will send an UPDATE with 1111. If 7777 answers and then 2222 hangs up, it will send an in-dialog INVITE. So you could test if it fails for both cases. But either way, 4K is sending the new details.

 

[infalex2xl]

it’s funny how much time I spent on this, it turns out that in the Yealink phone settings you just had to set callerid source = PAI-RPID-FROM and everything worked. I couldn't think that the problem was on the client.

 

[iiaacc]

There is no doubt that this problem occurs on devices other than Siemens, because OS4000 sends an update message with calling number in the SIP message. It's just that pjsip or the terminal didn't process it.