[asterisk-bugs] [JIRA] (ASTERISK-29257) "Received a REFER without a parseable Refer-To" from a technicolor gateway

[George Joseph (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253591#comment-253591 ] 

George Joseph commented on ASTERISK-29257:
------------------------------------------

That's weird since the ?header is part of the URI but user=phone is a header parameter not a URI parameter.  But that's neither here nor there.  Will require a pjproject patch.




> "Received a REFER without a parseable Refer-To" from a technicolor gateway
> --------------------------------------------------------------------------
>
>                 Key: ASTERISK-29257
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29257
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip, Resources/res_pjsip_refer
>    Affects Versions: 18.1.0
>         Environment: Linux
>            Reporter: Andrea Rossato
>            Severity: Minor
>
> Hello,
> I have a Technicolor gateway which, for transferring a call, is sending a SIP REFER which is rejected by asterisk with a "400 Bad Request" answer, complaining for the lack of a parseable "Refer-To" header in the REFER:
> {noformat}
> DEBUG[21954] res_pjsip_refer.c: Received a REFER without a parseable Refer-To ('<sip:4 at music.lan?Replaces=1972040-fedd8a9-9f53d9ac-ae2996b-9e80bdf-9E1BB4%3Bto-tag%3Dc372857e-4e48-4a70-87f3-792c0838c99d%3Bfrom-tag%3D1966a38-1b1bd16e-14d61b13-17e012b9-9e80bdf-9E1BB4>;user=phone') on channel 'PJSIP/operator-pen-00000000' from endpoint 'operator-pen'
> {noformat}
> This is the offending packet:
> {noformat}
> REFER sip:192.168.0.6:5060;user=phone SIP/2.0
> From: "penedallo"<sip:operator-pen at music.lan:5060;user=phone>;tag=1966558-25eae75e-c3a507af-559fc1f7-9e7e290-9E1BB4
> To: "3"<sip:3 at music.lan;user=phone>;tag=92441fad-6496-49ab-8260-faff2c9af10e
> Call-ID: 1972430-741f96ac-3d10d59-5aad30c9-9e7e290-9E1BB4
> CSeq: 4 REFER
> Via: SIP/2.0/UDP 192.168.0.254:5060;branch=z9hG4bK-28940-9e823f6-4c871a8e
> Refer-To: <sip:4 at music.lan?Replaces=1972040-fedd8a9-9f53d9ac-ae2996b-9e80bdf-9E1BB4%3Bto-tag%3Dc372857e-4e48-4a70-87f3-792c0838c99d%3Bfrom-tag%3D1966a38-1b1bd16e-14d61b13-17e012b9-9e80bdf-9E1BB4>;user=phone
> Referred-By: <sip:operator-pen at music.lan:5060>
> Max-Forwards: 70
> Supported: replaces,100rel
> User-Agent: Technicolor / VANT-6 / AGTOT_1.0.1 / AGTOT_1.0.1
> Contact: <sip:operator-pen at 192.168.0.254:5060;user=phone>
> Authorization: Digest username="operator-pen",realm="asterisk",nonce="1611229094/fe236d06961039f14c0dbb0c17920968",uri="sip:192.168.0.6:5060;user=phone",response="43c4b80877a443ca941bb369346f0f66",algorithm=MD5,cnonce="9e823f6",opaque="2d5a29c968283ecf",qop=auth,nc=00000003
> X-Serialnumber: CP1634RAYPH
> Accept: application/dtmf-relay, x-application/dtmf-relay, application/sdp
> Content-Length: 0
> {noformat}
> Something similar has been already reported:
> pjsip - REFER request from SNOM is rejected with "400 bad request" - DEBUG shows "Received a REFER without a parseable Refer-To"
> ASTERISK-24508
> In that case, though, the offending "Refer-To" header was slightly different:
> {noformat}
> DEBUG[1748] res_pjsip_refer.c: Received a REFER without a parseable Refer-To ('sip:603 at 192.168.1.8;user=phone?Replaces=545ce68db624-gdhc4gp41882%3Bto-tag%3Da0b21fa1-e26d-4a56-b553-a79f329e58f2%3Bfrom-tag%3D2mlnkcxazi') on channel 'PJSIP/601-00000006' from endpoint '601'
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)