On 29 Nov 2013, at 12:48, Jan Gaida <[email protected]> wrote:
> Hello,
>
> The scenario is an attended transfer to a remote domain.
>
> The short description:
> When Asterisk receives a REFER message with a refer-to header that contains
> "?replaces=" query, in chan_sip's function "get_refer_info" the domain is
> extracted with the query-part. That leads to an error (no such host) when
> trying to send the INVITE to this domain.
>
> The solution is to remove the query part ('?') in the get_refer_info function
> (see attached diff file).
>
> ---
>
> The following is a description of the events like a SIP trace; with A being
> transferor, B transferee (Asterisk) and C the transfer-target.
>
> Two calls are established: call1 between B and A, and call2 between A and C.
> When starting the transfer, the transferor A sends a REFER to Asterisk (B):
> A -> REFER (Refer-to: <sip:C@domain?replaces=call2>) -> B
> B -> 202 Accepted -> A
> B -> Notify sipfrag 200 ok -> A
> A -> 200 ok -> B
>
> Now, there should be an outgoing INIVTE with Replaces header:
> B -> INVITE (Replaces: call2) > C
> But this INVITE never is send.
>
> In Asterisk's traces you see the following:
> chan_sip.c: Attended transfer: Will use Replace-Call-ID : call2 (No check
> of from/to tags)
> chan_sip.c: SIP transfer to extension C@internal by A@domain
> chan_sip.c: This SIP transfer is to a remote SIP extension (remote domain
> domain?Replaces=call2)
>
> Here you can see the error ^^^^. The remote domain still contains the query
> part (?Replaces) of the uri.
>
> The traces then continue:
> chan_sip.c: SIP attended transfer: Still not our call - generating INVITE
> with replaces
>
> Then it enters the dialplan where it is redirected with a Dial command:
> logger.c: -- Executing [s@callreferred:4] Dial("SIP/domain-09a40b60",
> "SIP/C@domain?Replaces=call2|60|") in new stack
>
> And finally the error:
> WARNING[32395] chan_sip.c: No such host: domain?Replaces=call2
> DEBUG[32395] chan_sip.c: Cant create SIP call - target device not registered
>
> ---
>
> With the attached patch, Asterisk behaves as expected. Should I open an
> issue on the tracker?
yes, thank you!
/O
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
