I have a PJSIP endpoint named ‘foo’ connected via WebSocket. When I received the inbound call, I was hoping to see the ‘To’ header as ‘To: sip:foo@mydomain.com,’ but instead, I got ‘To: sip:h9d5ofgk@my-ip-address’ which appears to be a random address with my IP (resembling a Contact address).
Is this how Asterisk is supposed to work, or is there a misconfiguration on my end?
On an inbound call, Asterisk logs whatever was received.
Not at the log. The actual Invite SIP Message received at UAC had that.
I think need give more info about setup.
In the 3 part I was expecting To address to be foo@mydomain.com instead To address has Contact address of foo.
UACs never receive INVITEs. INVITEs are requests and UACs can only send them. A UA can have both UAS and UAC roles.
That’s how SIP works the Contact address is used to form the request URI and the preferred value of the To header is the same as the request URI. chan_pjsip can override the request URI used with a registered contact, basically in the same way as you do when calling to a provider. That will have the side effect of changing the To header, as well.
My apologies for previously using “UAC” loosely. That was my mistake.
Upon reviewing RFC 3261, I have a different impression. Here’s an example of an INVITE message from RFC:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
And here’s an example of a response from Bob:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
In the response, Bob’s contact is specified as <sip:bob@192.0.2.4> , but the Request-URI and To header in the INVITE request contain sip:bob@biloxi.com , which is the logical recipient of the request.
Here is excerpt from RFC regarding TO header.
The To header field specifies the logical recipient of the request.
The optional “display-name” is meant to be rendered by a human-user
interface. The “tag” parameter serves as a general mechanism for
dialog identification.
Why is this implementation details important for me?
I am building a custom SIP client that relies on the To header field for further request processing. My assumption was that it would provide the correct display name and SIP address, which would allow me to identify the user.
It doesn’t work like you are wanting in Asterisk, you’d have to modify things.
Asterisk is acting as a registrar here, and so is translating the address of record into the actual address needed to contact the the registered destination. That means the request URI is the contact address from the register request.
The next bit is more arguable. For a proxy, it would pass the To address through, but it is a user agent, so follows the guidance for user agents, which is to set the To header to request URI. One could argue that it should set it to the request URI before the registrar lookup, but I don’t think the RFC gives explicit guidance on that.
I understand it, and I can see why it has been designed that way. Bob might get registered from a device or proxy where his URI might be different; for example, it might be bob123@office.com.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.