[asterisk-users] SIP reply CALL-ID from ITSP has internal address in host part
Andrew Stewart
astewart at notre1.com
Wed Sep 9 17:10:38 CDT 2009
On Wed, Sep 9, 2009 at 10:45 AM, Andrew Stewart <astewart at notre1.com> wrote:
> On Wed, Sep 9, 2009 at 8:59 AM, Alex Balashov<abalashov at evaristesys.com> wrote:
>> Andrew Stewart wrote:
>>
>>> We are using using what Cisco's Port Address Translation, so that all
>>> SIP traffic is done through %EXTERNIP%. To any outside box, it should
>>> look like the asterisk server is actually on %EXTERNIP%.
>>>
>>> My SIP packet gets sent to the ITSP with a Call-ID:
>>> 2fd557964ca936b66661d72f1328c918@%EXTERNIP% , but the SIP 200 OK reply
>>> from ITSP has Call-ID: 2fd557964ca936b66661d72f1328c918@%INTERNIP%. I
>>> can not figure out where the ITSP is even getting my %INTERNIP% from,
>>> I don't see it in the packet anywhere.
>>
>> This doesn't seem quite right. If the 200 OK reply is truly for the
>> INVITE (or whatever other transaction is initiated by your "SIP
>> packet"), it *must* have the *same* Call-ID per the RFC, otherwise it's
>> not a valid reply.
>>
>> The Call-ID is what's called a GUID (Globally Unique IDentifier). It is
>> up to every SIP user agent to generate one, and the only requirement is
>> that it be as unique as practical in time and SIP space. Many network
>> elements like to tack on IP addresses in the GUID as a means of
>> differentiating it further, though personally I think that's a bad idea.
>>
>> Would you mind pasting a capture of the transaction in question, from
>> the vantage point of the outside interface of your Asterisk host? You
>> can change the representations of the external IP to something else if
>> you don't want to post it to a public list.
>>
>> Thanks,
>>
>> --
>> Alex Balashov - Principal
>> Evariste Systems
>> Web : http://www.evaristesys.com/
>> Tel : (+1) (678) 954-0670
>> Direct : (+1) (678) 954-0671
>>
>> _______________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
>> Register Now: http://www.astricon.net
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
> Wireshark export of two packets pasted below. I simply did a
> find/relace and put "%EXTERNIP%" in place of my actual public, PATed,
> IP address. That is only modification I did to these pcaps.
>
> ====================================================================
>
> No. Time Source Destination Protocol Info
> 1 0.000000 192.168.114.64 209.62.1.2 SIP
> Request: OPTIONS sip:sip.us1.voip.ms
>
> Frame 1 (544 bytes on wire, 544 bytes captured)
> Arrival Time: Sep 4, 2009 13:36:02.490711000
> [Time delta from previous captured frame: 0.000000000 seconds]
> [Time delta from previous displayed frame: 0.000000000 seconds]
> [Time since reference or first frame: 0.000000000 seconds]
> Frame Number: 1
> Frame Length: 544 bytes
> Capture Length: 544 bytes
> [Frame is marked: False]
> [Protocols in frame: eth:ip:udp:sip]
> [Coloring Rule Name: UDP]
> [Coloring Rule String: udp]
> Ethernet II, Src: Dell_95:35:26 (00:22:19:95:35:26), Dst:
> Cisco_7d:53:80 (00:0e:38:7d:53:80)
> Destination: Cisco_7d:53:80 (00:0e:38:7d:53:80)
> Address: Cisco_7d:53:80 (00:0e:38:7d:53:80)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> Source: Dell_95:35:26 (00:22:19:95:35:26)
> Address: Dell_95:35:26 (00:22:19:95:35:26)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> Type: IP (0x0800)
> Internet Protocol, Src: 192.168.114.64 (192.168.114.64), Dst:
> 209.62.1.2 (209.62.1.2)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> 0000 00.. = Differentiated Services Codepoint: Default (0x00)
> .... ..0. = ECN-Capable Transport (ECT): 0
> .... ...0 = ECN-CE: 0
> Total Length: 530
> Identification: 0x6abe (27326)
> Flags: 0x00
> 0... = Reserved bit: Not set
> .0.. = Don't fragment: Not set
> ..0. = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: UDP (0x11)
> Header checksum: 0x08f4 [correct]
> [Good: True]
> [Bad : False]
> Source: 192.168.114.64 (192.168.114.64)
> Destination: 209.62.1.2 (209.62.1.2)
> User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
> Source port: sip (5060)
> Destination port: sip (5060)
> Length: 510
> Checksum: 0x0739 [validation disabled]
> [Good Checksum: False]
> [Bad Checksum: False]
> Session Initiation Protocol
> Request-Line: OPTIONS sip:sip.us1.voip.ms SIP/2.0
> Method: OPTIONS
> Request-URI: sip:sip.us1.voip.ms
> Request-URI Host Part: sip.us1.voip.ms
> [Resent Packet: False]
> Message Header
> Via: SIP/2.0/UDP %EXTERNIP%:5060;branch=z9hG4bK69fa843c;rport
> Transport: UDP
> Sent-by Address: %EXTERNIP%
> Sent-by port: 5060
> Branch: z9hG4bK69fa843c
> RPort: rport
> From: "asterisk" <sip:asterisk@%EXTERNIP%>;tag=as11d62f85
> SIP Display info: "asterisk"
> SIP from address: sip:asterisk@%EXTERNIP%
> SIP from address User Part: asterisk
> SIP from address Host Part: %EXTERNIP%
> SIP tag: as11d62f85
> To: <sip:sip.us1.voip.ms>
> SIP to address: sip:sip.us1.voip.ms
> SIP to address Host Part: sip.us1.voip.ms
> Contact: <sip:asterisk@%EXTERNIP%>
> Contact Binding: <sip:asterisk@%EXTERNIP%>
> URI: <sip:asterisk@%EXTERNIP%>
> SIP contact address: sip:asterisk@%EXTERNIP%
> Call-ID: 7c00900f10da2fe17739e79b5cfd0a49@%EXTERNIP%
> CSeq: 102 OPTIONS
> Sequence Number: 102
> Method: OPTIONS
> User-Agent: Asterisk PBX
> Max-Forwards: 70
> Date: Fri, 04 Sep 2009 18:36:02 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> Supported: replaces
> Content-Length: 0
>
> No. Time Source Destination Protocol Info
> 2 0.031174 209.62.1.2 192.168.114.64 SIP
> Status: 200 OK
>
> Frame 2 (531 bytes on wire, 531 bytes captured)
> Arrival Time: Sep 4, 2009 13:36:02.521885000
> [Time delta from previous captured frame: 0.031174000 seconds]
> [Time delta from previous displayed frame: 0.031174000 seconds]
> [Time since reference or first frame: 0.031174000 seconds]
> Frame Number: 2
> Frame Length: 531 bytes
> Capture Length: 531 bytes
> [Frame is marked: False]
> [Protocols in frame: eth:ip:udp:sip]
> [Coloring Rule Name: UDP]
> [Coloring Rule String: udp]
> Ethernet II, Src: Cisco_7d:53:80 (00:0e:38:7d:53:80), Dst:
> Dell_95:35:26 (00:22:19:95:35:26)
> Destination: Dell_95:35:26 (00:22:19:95:35:26)
> Address: Dell_95:35:26 (00:22:19:95:35:26)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> Source: Cisco_7d:53:80 (00:0e:38:7d:53:80)
> Address: Cisco_7d:53:80 (00:0e:38:7d:53:80)
> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
> .... ..0. .... .... .... .... = LG bit: Globally unique
> address (factory default)
> Type: IP (0x0800)
> Internet Protocol, Src: 209.62.1.2 (209.62.1.2), Dst: 192.168.114.64
> (192.168.114.64)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> 0000 00.. = Differentiated Services Codepoint: Default (0x00)
> .... ..0. = ECN-Capable Transport (ECT): 0
> .... ...0 = ECN-CE: 0
> Total Length: 517
> Identification: 0x0871 (2161)
> Flags: 0x00
> 0... = Reserved bit: Not set
> .0.. = Don't fragment: Not set
> ..0. = More fragments: Not set
> Fragment offset: 0
> Time to live: 49
> Protocol: UDP (0x11)
> Header checksum: 0x7a4e [correct]
> [Good: True]
> [Bad : False]
> Source: 209.62.1.2 (209.62.1.2)
> Destination: 192.168.114.64 (192.168.114.64)
> User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
> Source port: sip (5060)
> Destination port: sip (5060)
> Length: 497
> Checksum: 0xcf3d [validation disabled]
> [Good Checksum: False]
> [Bad Checksum: False]
> Session Initiation Protocol
> Status-Line: SIP/2.0 200 OK
> Status-Code: 200
> [Resent Packet: False]
> Message Header
> Via: SIP/2.0/UDP
> 192.168.114.64:5060;branch=z9hG4bK69fa843c;received=192.168.114.64;rport=5060
> Transport: UDP
> Sent-by Address: 192.168.114.64
> Sent-by port: 5060
> Branch: z9hG4bK69fa843c
> Received: 192.168.114.64
> RPort: 5060
> From: "asterisk" <sip:asterisk at 192.168.114.64>;tag=as11d62f85
> SIP Display info: "asterisk"
> SIP from address: sip:asterisk at 192.168.114.64
> SIP from address User Part: asterisk
> SIP from address Host Part: 192.168.114.64
> SIP tag: as11d62f85
> To: <sip:sip.us1.voip.ms>;tag=as6addea65
> SIP to address: sip:sip.us1.voip.ms
> SIP to address Host Part: sip.us1.voip.ms
> SIP tag: as6addea65
> Call-ID: 7c00900f10da2fe17739e79b5cfd0a49 at 192.168.114.64
> CSeq: 102 OPTIONS
> Sequence Number: 102
> Method: OPTIONS
> User-Agent: VoIPMS/SERAST
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
> Supported: replaces
> Contact: <sip:209.62.1.2>
> Contact Binding: <sip:209.62.1.2>
> URI: <sip:209.62.1.2>
> SIP contact address: sip:209.62.1.2
> Accept: application/sdp
> Content-Length: 0
>
> ====================================================================
>
> -aws
>
Figured out the problem. There is an "inspect sip" command in our
global policy map on our Cisco ASA firewall. That was "fixing" the
CALL-ID. Took it out and all is working now.
-aws
More information about the asterisk-users
mailing list