[Home]

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:20Date Closed:2011-06-07 14:00:18
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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:823013212069848@192.168.1.221 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.10:5060;branch=z9hG4bK2ebb3639;rport
Max-Forwards: 70
From: "3614296471" <sip:3614296471@192.168.1.221>;tag=as02da3780 Should be from our IP.
To: <sip:823013212069848@192.168.1.221>
Contact: <sip:3614296471@10.1.1.10>
Call-ID: 4f7b5aa40310f3871f3995de46a1137c@192.168.1.221
CSeq: 102 INVITE
User-Agent: Cisco 3845
Remote-Party-ID: "3614296471" <sip:3614296471@192.168.1.221>;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:+13614296471@10.1.1.10>
Content-Type: application/sdp
Content-Length: 295


****** ADDITIONAL INFORMATION ******

http://www.faqs.org/rfcs/rfc3261.html

8.1.1.3 From

  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
  names.

  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:thisis@anonymous.invalid), 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.
  Examples:

     From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
     From: sip:+12125551212@phone2net.com;tag=887s
     From: Anonymous <sip:c8oqz84zk7z@privacy.org>;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:823012148761404@xxx.78.161.xx:5060 SIP/2.0
Via: SIP/2.0/UDP 65.xx.254.xx:5060;branch=z9hG4bK57247301-bdb1079462552
From: <sip:2145551212@65.90.254.20>;tag=5724730-fdb1079462552
To: <sip:823012148761404@xxx.78.161.xx:5060>
Call-ID: 213-1-1239085615@65.xx.254.xx
CSeq: 1 INVITE
Server: Sansay VSX 2.1
Contact: <sip:2145551212@65.xx.254.xx:5060;transport=udp>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length:   257
v=0
o=sansay-VSX 10 10 IN IP4 24.x.44.xxx
s=session controller
c=IN IP4 24.x.44.xxx
t=0 0
m=audio 43456 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
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.