Outbound registration 'line' not being used correctly?

brian_j_murrell · December 30, 2020, 3:26pm

I followed @jcolp’s blog post to add the line= option to my Contact: header and it appears to be working:

<--- Transmitting SIP request (743 bytes) to UDP:1.2.3.4:5060 --->
REGISTER sip:itsp4.example.com SIP/2.0
Via: SIP/2.0/UDP 10.75.22.8:5060;rport;branch=z9hG4bKPjb16d134c-3210-45ba-8acd-0b33f7899327
From: <sip:my_itsp_account@itsp4.example.com>;tag=56138ab9-8c52-43a6-814f-9cb70285b5b1
To: <sip:my_itsp_account@itsp4.example.com>
Call-ID: 9170809e-ab7a-4b22-b74f-c4528c419dc3
CSeq: 30765 REGISTER
Contact: <sip:1235551212@10.75.22.8:5060;line=abcdefg>
Expires: 3600
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Max-Forwards: 70
User-Agent: Asterisk PBX 13.38.1
Authorization: Digest username="my_itsp_account", realm="itsp4.example.com", nonce="[redacted]", uri="sip:itsp4.example.com", response="[redacted]", algorithm=MD5
Content-Length:  0


<--- Received SIP response (610 bytes) from UDP:1.2.3.4:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.75.22.8:5060;branch=z9hG4bKPjb16d134c-3210-45ba-8acd-0b33f7899327;received=10.75.22.8;rport=5060
From: <sip:my_itsp_account@itsp4.example.com>;tag=56138ab9-8c52-43a6-814f-9cb70285b5b1
To: <sip:my_itsp_account@itsp4.example.com>;tag=as15e6a747
Call-ID: 9170809e-ab7a-4b22-b74f-c4528c419dc3
CSeq: 30765 REGISTER
Server: example.com
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 3600
Contact: <sip:1235551212@10.75.22.8:5060;line=abcdefg>;expires=3600
Date: Wed, 30 Dec 2020 16:35:06 GMT
Content-Length: 0

And when I receive an INVITE from my ITSP for a call being routed to me, the INVITE looks like:



<--- Received SIP request (1025 bytes) from UDP:1.2.3.4:5060 --->
INVITE sip:1235551212@10.75.22.8:5060 SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK4bc4d517;rport
Max-Forwards: 70
From: "Loopback" <sip:1235551212@1.2.3.4>;tag=as25d6c8c3
To: <sip:1235551212@10.75.22.8:5060>
Contact: <sip:1235551212@1.2.3.4:5060>
Call-ID: 397efeaa4c5caa040d4dbd952eee2ae0@1.2.3.4:5060
CSeq: 102 INVITE
User-Agent: example.com
Date: Wed, 30 Dec 2020 17:05:41 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
X-Dest-User: my_itsp_account
Remote-Party-ID: "Loopback" <sip:1235551212@1.2.3.4>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 317

I don’t see the line=abcdefg anywhere in that INVITE. Am I missing it or is this ITSP violating the requirement that the remote server is supposed to call us using the Contact we provide to them?

Is this requirement written in an RFC somewhere that I can quote to them in getting them to fix this?

Cheers.

jcolp · December 30, 2020, 3:57pm

The INVITE you’ve provided is not the one from the ITSP, but one originating from Asterisk.

brian_j_murrell · December 30, 2020, 5:21pm

Damn. You are right of course. I pulled the wrong INVITE since I was testing it by calling myself from the same Asterisk instance.

I’ve edited the original post to include a new REGISTER transaction and a subsequent INVITE from the ITSP.

david551 · December 30, 2020, 6:09pm

Looking at the SIP RFC and the IANA URI parameter registrations, I’m not convinced that there is any specific requirement to even rewrite the request URI. However, the obvious spirit would be that if it is rewritten, the whole contact URI would be used.

jcolp · December 30, 2020, 6:23pm

I forgot where I read the language, and like many things in SIP it’s probably not as black and white as one would hope. This language makes it seem as though it’s typical though:

Typically, a UA that uses the
   REGISTER method to bind its address-of-record to a specific contact
   address will see requests whose Request-URI equals that contact
   address.  Other potential sources of received Request-URIs include
   the Contact header fields of requests and responses sent by the UA
   that establish or refresh dialogs.

From https://tools.ietf.org/html/rfc3261#section-8.2.2.1

david551 · December 30, 2020, 6:28pm

Thanks. I missed that one.

brian_j_murrell · December 30, 2020, 7:08pm

I am correct in that they are not using the line= in the INVITE, yes?

If they were, what would look different in that INVITE request?

jcolp · December 30, 2020, 7:39pm

You are correct in that they are not using it. And the Request or To URI would contain the full Contact URI:

sip:1235551212@10.75.22.8:5060;line=abcdefg

david551 · December 30, 2020, 9:39pm

They shouldn’t need to know what line= means, they should simply copy the whole URI. Only a very few specific parameters are treated differently. line= isn’t actually defined in an official standard, so they should treat it as an opaque value to be returned unchanged.

brian_j_murrell · December 31, 2020, 2:11pm

@david551 Completely understood. I just wanted to make sure that I was indeed seeing what I thought I was seeing.

brian_j_murrell · January 6, 2021, 1:24pm

Can we be specific here about which these are? Specifically, in the INVITE from the ITSP, I should expect to see:

To: <sip:1235551212@10.75.22.8:5060;line=abcdefg>

which is the To URI, correct? What exactly is the Request you refer to given the example INVITE I provided from my ITSP?

jcolp · January 6, 2021, 1:25pm

The Request URI is the URI in the first line of the SIP INVITE.

brian_j_murrell · January 6, 2021, 1:27pm

So the:

INVITE sip:1235551212@10.75.22.8:5060 SIP/2.0

correct? So that should actually look like:

INVITE sip:1235551212@10.75.22.8:5060;line=abcdefg SIP/2.0

?

jcolp · January 6, 2021, 1:35pm

Yes. They commonly match but don’t have to. The “line” support examines both for the presence of the “line” parameter to associate things.

system · February 5, 2021, 1:35pm

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