Clarifications on refer attended

Asterisk Asterisk SIP
1

hi I’m trying to implement the Attended call transfer (the BLIND one already works) … From what I understand about the SIP TRANSFER via REFER call-flows regarding the Attended transfer, on the Refer-to header I have to add REPLACES = call -id & to-tag & from-tag. From what I understand Asterisk should do a RE-INVITE not INVITE … instead an INVITE starts and makes the Target phone ring forcing me to close the call before making the REFER otherwise it gives me busy.
What am I doing wrong? but above all I understood well with the REPLACES does not make a new call?
below I put an example of refer that I have implemented

the call-id in the REPLACES field is the one relating to the call between the Transferor and the target

thanks in advance and above all sorry for the inaccuracies I am not an asterisk expert

2

Refer-To: <sip: 224@192.168.21.204>? REPLACES = 4b750e90682f78be2972b640202b99f9% 40192.168.21.204% 3A5060% 3bto-tag% 3Das6fb0d10cfrom-tag% 3Dj2pok5yNx9

3

Your question isn’t really Asterisk, but SIP implementation related. For Asterisk it doesn’t do a re-INVITE, who is connected to who is just internally changed if it’s recognized as an attended transfer. If it’s not then it’d likely be treated as a blind transfer.

You could try turning up Asterisk core debug and seeing if res_pjsip_refer gives you any hint otherwise an actual full SIP trace of all involved calls would likely be needed.

4

thank you very much I will check what you suggested

5

And from a SIP point of view, there is nothing in REFER/Replaces that requires a Re-INVITE. In the most general case, the target of the request would need to generate INVITE, with a Replaces header, but this would be a full INVITE, not a Re-INVITE.

As noted, if the resulting INVITE would be sent to itself, which is normally the case, Asterisk will handle it internally and not physically send it. Only if the call ID and tags don’t match might it do that, and things then get a bit kludgy, as I recall it, as I think the dialplan has to be written in a specific way for it to actually work. I never tried this in anger.

Your target phone will be ringing because Asterisk doesn’t recognise the call-id and tags as being local, and probably also because the phone doesn’t recognize them either, possibly combined with not doing the right kludges in the dialplan.

You have some spaces in your quote code where they are not allowed (in the middle of escapes). You are also missing a delimiter before from-tag. Examples of a correctly formed Refer-To can be found on page 27 of RFC 5589: Session Initiation Protocol (SIP) Call Control - Transfer

PS it is a long time since I looked at the internals of this, so I’m not sure my comments about dialplan involvement are correct, but Asterisk is clearly not recognizing the replaced endpoint as local, probably because the Refer-To Replaces header request is garbled.

(Recalling a bit more, I think the issue with the dialplan is that Asterisk will put the outgoing INVITE, in a case that can’t be handled locally, through the dialplan using just the user part, and to get the INVITE sent to the correct place, the dialplan has to add back the correct domain, as, when you really need to send the INVITE, the destination isn’t typically something that is known to Asterisk.)

6

Thanks David551 for the clarifications
I add this figure so let’s see if I understand and if I have compiled the refer correctly (except upper or lower case which then I go to check in RFC5589).
From what you tell me an INVITE, after the REFER, starts only if, or the diaplan is not correctly coded, or the REFER itself is not filled in correctly … Correct? If the REFER is correct “C” (see figure) should not ring but “magically” A and C should be in communication … correct?
Let me know
Ps sorry again for my inaccuracies

refer
refer895×303 5.63 KB

7

Step 2 is at the discretion of the phone.

Step 4: only the tags, not the URIs have to match, although the URIs normally do. I don’t know the difference between C and C1.

Step 5: doesn’t exist.

Generally, though, this diagram is confusing, because it appears to show phones talking directly to each other, when they are really talking to Asterisk, e.g. step 1 is really A calls B@*, call ID A*1; from tag AA1; to tag **1, followed by * calls B@B; call ID *B1; from tag **2; to tag BB1 and the replaces for step 4 is really for call ID *B1; from tag **2; to tag BB1, and is directed at Asterisk, not at C, as step 3 is also really two steps.

The request URI in step 1a is that for the Asterisk extension corresponding to B, but in step 1b it is the actual URI of the device for B.

Notionally step 5 is an INVITE from Asterisk to Asterisk, but that is short circuited.

When I implemented this, many years ago, I got the to and from tags the wrong way round in the Replaces. I can’t’ guarantee that they are right here. I think they have to be based on what Asterisk would be using if it acted as a UAC in the step 3 session with B, or was that the mistake I made.

8

Thanks David,
Premise you are right that between the calls there is always asterisk in the middle but I thought that putting only the targets could be enough.
Anyway I made the corrections of the case thanks to your suggestions and studying the call-flow … I took a few steps forward … I no longer have the ring of the target phone … but I get busy I’m trying to understand where the called via asterisk logs and debugging my code.
Anyway I’ll give you a real situation:
I have 3 users all registered on the same Asterisk 221 - 223 - 224; the first two numbers are registered on the softtone I am implementing, the third is 3CXPhone.
The roles are:
221 Transferee
223 Transferor
224 Transfer Target

testo
testo952×2264 134 KB

Thank you so much

9

for clarity I will add only the most important info
The steps:

  1. I call 223 from 221
    Call-ID: 409f13de38937ec7758fafb8288e3a8b
    From: “User 221” <221>; tag = as1931069f
    To: 223

  2. I put 221 in HOLD
    RE-INVITE
    From: 223; tag = FbIfomIU
    To: 224; tag = as75bf0eec
    Call-ID: gvEdSBgU-1661337063157

  3. I call 224 from 223
    Call-ID: gvEdSBgU-1661337063157
    From: dev223; tag = FbIfomIU
    To: 224; tag = as75bf0eec

  4. I start the transfer from 221 to 224
    Call-ID: 409f13de38937ec7758fafb8288e3a8b
    From: dev223>; tag = 7K6B22srPd
    To: 221; tag = as1931069f
    Refer-To: 224? Replaces=409f13de38937ec7758fafb8288e3a8b; to-tag = 7K6B22srPd; from-tag = as1931069f
    Target-Dialog: gvEdSBgU-1661337063157; local-tag = as36d6e1e3; remote-tag = FbIfomIU

10

You can’t put a call on hold before you have started the session, which doesn’t happen until step 3.

All the replaces values are from the wrong session. They should reflect that from step 3, given the request is being made on the step 1 session.

There shouldn’t be spaces in the URI.

hvalue          =  *( hnv-unreserved / unreserved / escaped )
hnv-unreserved  =  "[" / "]" / "/" / "?" / ":" / "+" / "$"
unreserved  =  alphanum / mark
mark        =  "-" / "_" / "." / "!" / "~" / "*" / "'"
                     / "(" / ")"

Neither ; nor = are permitted in a header value in a SIP URI.

I’m not sure if Asterisk supports RFC 4538

I can’t guarantee whether the from and to tag are the right way round, without making detailed checks.

11

opps!!
you’re right I copied the wrong header

12

also for the spaces I had not noticed

13

Hi, David,
I took a few steps forward … now he tells me:
SIP / 2.0 481 Call leg / transaction does not exist.

I really don’t know where to look to understand the problem.
Do you have any suggestions?

I give you the INVITATIONS and the REFER as I use
INVITE sip: dev223@10.212.134.7: 53503; transport = UDP SIP / 2.0
Via: SIP / 2.0 / UDP 192.168.21.204:5060;branch=z9hG4bK2fe8a6d4
Max-Forwards: 70
From: “User 221” <sip: 221@192.168.21.204>; tag = as3fb67f4f
Contact: <sip: 221@192.168.21.204: 5060>
Call-ID: 22069ab16cba84173fa43e130193defb@192.168.21.204: 5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.22.0
Dates: Wed, 24 Aug 2022 21:55:45 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: “User 221” <sip: 221@192.168.21.204>; privacy = off; screen = no; party = calling
Content-Type: application / sdp
Content-Length: 242
To: <sip: dev223@10.212.134.7: 53503; transport = UDP>; tag = ZiAvLPcyGM

INVITE sip: 224@192.168.21.204 SIP / 2.0
Via: SIP / 2.0 / UDP 10.212.134.7:53503;rport;branch=z9hG4bKozpPYSNwG
Route: <sip: 192.168.21.204>
Max-Forwards: 70
From: <sip: dev223@192.168.21.204>; tag = 7AZ8NNy1
Call-ID: gMfVAetf-1661378165010 @ ITRM00DW129
CSeq: 3 ACK
Content-Length: 212
Content-Type: application / sdp
Supported: replaces
Allow: REGISTER, INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip: dev223@10.212.134.7: 53503; transport = UDP>
To: <sip: 224@192.168.21.204>; tag = as5cb84d7a

REFER sip: 221@192.168.21.204: 5060 SIP / 2.0
To: <sip: 221@192.168.21.204>; tag = as3fb67f4f
From: <sip: dev223@10.212.134.7: 53503; transport = UDP>; tag = ZiAvLPcyGM
Call-ID: 22069ab16cba84173fa43e130193defb@192.168.21.204: 5060
CSeq: 830689082 REFER
Max-Forwards: 70
Authorization: Digest username = “dev223”, realm = “asterisk”, nonce = “2a7df249”, uri = “sip: 224@192.168.21.204”, response = “138724bdd2d0e5aa52f67916c492d8f5”
Refer-To: <sip: 224@192.168.21.204? Replaces = 22069ab16cba84173fa43e130193defb% 40192.168.21.204% 3A5060% 3bto-tag% 3DZiAvLPcyGM% 3bfrom-tag% 3Das3fb67f4f>
Target-Dialog: gMfVAetf-1661378165010% 40ITRM00DW129; local-tag = 7AZ8NNy1; remote-tag = as5cb84d7a
Supported: gruu, replaces, tdialog
Require: tdialog

14

You don’t appear to have marked up the log as preformatted text.

I can’t check all the tags as you haven’t included any of the responses.

It looks like you’ve only provided the second REFER. There wouldn’t be a second REFER if the session matched, and the REFER would not need authentication.

The second INVITE has an invalid CSEQ header.

The tags and call-id in the Replaces parameter are for the wrong session.

The second INVITE is a re-INVITE, not an initial INVITE. Where is the initial INVITE?

15

thanks David,
I solved it thanks to your precious information

16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.