server should add a Contact header to REFER if necessary

[davehorton]

A succesful REFER request creates an implicit subscription, but a Contact header is needed in order for the receiving UA to know where to send NOTIFY messages

[spointer]

Hi, Dave.

I'm not sure if this issue is relevant, but if REFER is sent, there's no response. And it seems that call-id changes every time drachtio-server sends REFER over and over. Is this correct? Thank you.

2019-07-03 13:58:09.595506 send 759 bytes to udp/[xxx.xxx.xx.xxx]:5060 at 13:58:09.595301: INVITE sip:[email protected]:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP yyy.yyy.yy.yyy:5060;rport;branch=z9hG4bK1K7USc08X9Qgc Route: sip:xxx.xxx.xx.xxx;lr Max-Forwards: 70 From: sip:[email protected];tag=Qc6FKFytcZr0g To: sip:[email protected];tag=a236501d74caa833f5244dcac6d39a39 Call-ID: xxx.xxx.xx.xxx_AAAJ-X__BGYAABez0-lBRw--c6276@com CSeq: 605202 INVITE Contact: sip:yyy.yyy.yy.yyy:5060 Content-Type: application/sdp Content-Length: 265

v=0 o=- 351236372 351236374 IN IP4 zzz.zzz.zz.zzz s=cogi c=IN IP4 zzz.zzz.zz.zzz t=0 0 m=audio 10774 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=maxptime:150 a=inactive 2019-07-03 13:58:09.693462 recv 682 bytes from udp/[xxx.xxx.xx.xxx]:5060 at 13:58:09.693263: SIP/2.0 200 OK Via: SIP/2.0/UDP yyy.yyy.yy.yyy:5060;rport;branch=z9hG4bK1K7USc08X9Qgc From: sip:[email protected];tag=Qc6FKFytcZr0g To: sip:[email protected];tag=a236501d74caa833f5244dcac6d39a39 Record-Route: sip:xxx.xxx.xx.xxx;lr Call-ID: xxx.xxx.xx.xxx_AAAJ-X__BGYAABez0-lBRw--c6276@com CSeq: 605202 INVITE Contact: sip:[email protected]:5060;user=phone Content-Type: application/sdp Content-Length: 223

v=0 o=- 351236372 351236373 IN IP4 xxx.xxx.xx.xxx s=ENSResip c=IN IP4 xxx.xxx.xx.xxx t=0 0 m=audio 20080 RTP/AVP 0 101 a=fmtp:101 0-11 a=ptime:20 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=recvonly 2019-07-03 13:58:09.696409 send 419 bytes to udp/[xxx.xxx.xx.xxx]:5060 at 13:58:09.696265: ACK sip:[email protected]:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP yyy.yyy.yy.yyy:5060;rport;branch=z9hG4bK2v0mU7gcUje3Q Route: sip:xxx.xxx.xx.xxx;lr Max-Forwards: 70 From: sip:[email protected];tag=Qc6FKFytcZr0g To: sip:[email protected];tag=a236501d74caa833f5244dcac6d39a39 Call-ID: xxx.xxx.xx.xxx_AAAJ-X__BGYAABez0-lBRw--c6276@com CSeq: 605202 ACK Content-Length: 0

2019-07-03 13:58:09.698665 send 471 bytes to udp/[xxx.xxx.xx.xxx]:5060 at 13:58:09.698528: REFER sip:[email protected]:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP yyy.yyy.yy.yyy:5060;rport;branch=z9hG4bK35SDX21FrU4NK Route: sip:xxx.xxx.xx.xxx;lr Max-Forwards: 70 From: sip:[email protected];tag=Qc6FKFytcZr0g To: sip:[email protected];tag=a236501d74caa833f5244dcac6d39a39 Call-ID: xxx.xxx.xx.xxx_AAAJ-X__BGYAABez0-lBRw--c6276@com CSeq: 605203 REFER Refer-To: sip:[email protected]:5060 Content-Length: 0

2019-07-03 13:58:09.703523 recv 461 bytes from udp/[xxx.xxx.xx.xxx]:5060 at 13:58:09.703397: REFER sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/UDP xxx.xxx.xx.xxx:5060;branch=z9hG4bK35SDX21FrU4NK From: sip:[email protected];tag=a236501d74caa833f5244dcac6d39a39 To: sip:[email protected];tag=14ef7114-co6052-INS001 Record-Route: sip:xxx.xxx.xx.xxx;lr Call-ID: AAAJ-X__BGYAABez0-lBRw--c6276@com CSeq: 605203 REFER Max-Forwards: 70 Refer-To: sip:[email protected]:5060 Content-Length: 0

2019-07-03 13:58:10.699860 send 471 bytes to udp/[xxx.xxx.xx.xxx]:5060 at 13:58:10.699638: REFER sip:[email protected]:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP yyy.yyy.yy.yyy:5060;rport;branch=z9hG4bK35SDX21FrU4NK Route: sip:xxx.xxx.xx.xxx;lr Max-Forwards: 70 From: sip:[email protected];tag=Qc6FKFytcZr0g To: sip:[email protected];tag=a236501d74caa833f5244dcac6d39a39 Call-ID: xxx.xxx.xx.xxx_AAAJ-X__BGYAABez0-lBRw--c6276@com CSeq: 605203 REFER Refer-To: sip:[email protected]:5060 Content-Length: 0

2019-07-03 13:58:10.706903 recv 461 bytes from udp/[xxx.xxx.xx.xxx]:5060 at 13:58:10.706739: REFER sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/UDP xxx.xxx.xx.xxx:5060;branch=z9hG4bK35SDX21FrU4NK From: sip:[email protected];tag=a236501d74caa833f5244dcac6d39a39 To: sip:[email protected];tag=14ef7114-co6052-INS001 Record-Route: sip:xxx.xxx.xx.xxx;lr Call-ID: AAAJ-X__BGYAABez0-lBRw--c6276@com CSeq: 605203 REFER Max-Forwards: 70 Refer-To: sip:[email protected]:5060 Content-Length: 0

[davehorton]

Hmm, I cannot explain the shifting call-id. That is very strange. As to the need for a Contact header on a REFER, I forgot this issue was still open. Do you have the ability to test a fix if I create a branch or a custom docker image? Are you using docker or building from source?

[spointer]

I'm using docker and if you create a branch, i'll build a custom docker image, test and let you know the result.

Note that the deleted part is an ip address. That is, the Call-ID begins with an ip address.

Thank you.

[spointer]

Hi, Dave. I'm sorry i misrepresented the log. If i send REFER request, i receive REFER response with the shifted Call-ID from the remote SIP server. In normal cases, isn't it right to respond 202 status?

Thank you.

[davehorton]

I actually dont see a REFER response in your log. I see a REFER request coming back after you send a REFER request. And it has the shifted/messed up call id. So this seems to be a problem with the remote server --- because, as you say, the expected sequence is for them to send a 202 Accepted, followed by NOTIFYs.

I will still make the change to add a Contact header on the REFER but it seems you have some sort of problem with the downstream element.

[davehorton]

please retest with the latest on the develop branch (or drachtio/drachtio-server:latest) once it finishes building.

[davehorton]

any chance you have been able to retest with this fix?