|Summary:||ASTERISK-13907: Outbound Invite has the from field and Remote-Party-ID bad|
|Reporter:||Private Name (falves11)||Labels:|
|Date Opened:||2009-04-06 18:32:20||Date Closed:||2011-06-07 14:00:18|
|Description:||I found something that affects interoperability badly. I am sending an invite to IP 192.168.1.221, from an Asterismk with IP 10.1.1.10. The From header and the Remote-Party-ID headers have the wrong IP, it should be the Asterisk, the sender's IP, not the target IP. I checked in the RFC and it is clear that the from header contains the originator's IP. Several of my carriers stopped working. I need to keep using this version, because it does not blow up, SVN-branch-1.6.2-r186654M , instead of any other one. Somebody please fix it.|
INVITE sip:email@example.com SIP/2.0
Via: SIP/2.0/UDP 10.1.1.10:5060;branch=z9hG4bK2ebb3639;rport
From: "3614296471" <sip:firstname.lastname@example.org>;tag=as02da3780 Should be from our IP.
CSeq: 102 INVITE
User-Agent: Cisco 3845
Remote-Party-ID: "3614296471" <sip:email@example.com>;privacy=off;screen=yes Should be from our IP.
Date: Mon, 06 Apr 2009 21:51:17 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
P-Asserted-Identity: "" <sip:+firstname.lastname@example.org>
****** ADDITIONAL INFORMATION ******
The From header field indicates the logical identity of the initiator
of the request, possibly the user's address-of-record. Like the To
header field, it contains a URI and optionally a display name. It is
used by SIP elements to determine which processing rules to apply to
a request (for example, automatic call rejection). As such, it is
very important that the From URI not contain IP addresses or the FQDN
of the host on which the UA is running, since these are not logical
The From header field allows for a display name. A UAC SHOULD use
the display name "Anonymous", along with a syntactically correct, but
otherwise meaningless URI (like sip:email@example.com), if the
identity of the client is to remain hidden.
Usually, the value that populates the From header field in requests
generated by a particular UA is pre-provisioned by the user or by the
administrators of the user's local domain. If a particular UA is
used by multiple users, it might have switchable profiles that
include a URI corresponding to the identity of the profiled user.
Recipients of requests can authenticate the originator of a request
in order to ascertain that they are who their From header field
claims they are (see Section 22 for more on authentication).
The From field MUST contain a new "tag" parameter, chosen by the UAC.
See Section 19.3 for details on choosing a tag.
For further information on the From header field, see Section 20.20.
From: "Bob" <sips:firstname.lastname@example.org> ;tag=a48s
From: Anonymous <sip:email@example.com>;tag=hyh8
|Comments:||By: Private Name (falves11) 2009-04-06 20:11:45|
I checked version 1.4 and in fact it has the same issue. I have a vendor, Verizon, which is maybe the most important US carrier, who requires this issue fixed. If it breakes anything else then we should make it into configurable option, pero peer. But the RFC is clear about this.
By: Private Name (falves11) 2009-04-07 01:39:36
I checked another switch, Sansay, and as you can see below, it is perfect. So Asteris has bug.
INVITE TO PROVIDER:
INVITE sip:firstname.lastname@example.org:5060 SIP/2.0
Via: SIP/2.0/UDP 65.xx.254.xx:5060;branch=z9hG4bK57247301-bdb1079462552
CSeq: 1 INVITE
Server: Sansay VSX 2.1
o=sansay-VSX 10 10 IN IP4 24.x.44.xxx
c=IN IP4 24.x.44.xxx
m=audio 43456 RTP/AVP 0 18 101
By: Mark Michelson (mmichelson) 2009-04-07 09:53:59
Please upload your sip.conf.
By: Private Name (falves11) 2009-04-07 10:20:19
Please close the case. I solved it. It was not a bug.