[Asterisk-Dev] SIP handling of Contact header with new port

[Olle E. Johansson]

Ed Greenberg wrote:
> This is observed with 1.2.0, not CVS.
> 
> When a sip peer that is behind NAT is invited, it returns a contact
> header with a port other than 5060 in it's 180 and 200 messages. For
> instance:
> 
>    -- Called otherguy/04082098516
> ev02a*CLI>
> <-- SIP read from 1xx.yy.zz.aa:5060:
> SIP/2.0 100 Trying
> Call-ID: 64c034d2254d5edb7216047073e150c2 at 1aa.bbb.ccc.ddd
> Via: SIP/2.0/UDP 1aa.bbb.ccc.ddd:5060;branch=z9hG4bK30bbe558;rport
> From: "+13115552368" <sip:+13115552368 at 1aa.bbb.ccc.ddd>;tag=as3a9d8dca
> To: <sip:18887776666 at 1xx.yy.zz.aa:5060>
> CSeq: 102 INVITE
> Content-Length: 0
> 
> 
> --- (7 headers 0 lines)---
> ev02a*CLI>
> <-- SIP read from 1xx.yy.zz.aa:5060:
> SIP/2.0 180 Ringing
> Call-ID: 64c034d2254d5edb7216047073e150c2 at 1aa.bbb.ccc.ddd
> Via: SIP/2.0/UDP 1aa.bbb.ccc.ddd:5060;branch=z9hG4bK30bbe558
> From: "+13115552368" <sip:+13115552368 at 1aa.bbb.ccc.ddd>;tag=as3a9d8dca
> To: <sip:18887776666 at 1xx.yy.zz.aa:5060>;tag=0a94b5e7
> CSeq: 102 INVITE
> Contact: <sip:18887776666 at 1xx.yy.zz.aa:32801>
> Allow:  OPTIONS, INVITE, CANCEL, ACK, BYE, INFO
> Content-Disposition: session; handling=required
> Content-Type: application/sdp
> Content-Length: 164
> 
> v=0
> o=Sonus_UAC 1383 25405 IN IP4 1xx.yy.zz.aa
> s=SIP Media Capabilities
> c=IN IP4 1xx.yy.zz.aa
> t=0 0
> m=audio 32836 RTP/AVP 0
> a=rtpmap:0 PCMU/8000
> a=sendrecv
> 
> And then...
> 
> --- (11 headers 8 lines)---
> Found RTP audio format 0
> Peer audio RTP is at port 1xx.yy.zz.aa:32836
> Found description format PCMU
> Capabilities: us - 0x4 (ulaw), peer - audio=0x4 (ulaw)/video=0x0
> (nothing), combined - 0x4 (ulaw)
> Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x0
> (nothing), combined - 0x0 (nothing)
>    -- SIP/otherguy-0c77 is ringing
>    -- SIP/otherguy-0c77 is making progress passing it to
> SIP/64.156.10.50-097f01c0
> ev02a*CLI>
> <-- SIP read from 1xx.yy.zz.aa:5060:
> SIP/2.0 200 OK
> Call-ID: 64c034d2254d5edb7216047073e150c2 at 1aa.bbb.ccc.ddd
> Via: SIP/2.0/UDP 1aa.bbb.ccc.ddd:5060;branch=z9hG4bK30bbe558
> From: "+13115552368" <sip:+13115552368 at 1aa.bbb.ccc.ddd>;tag=as3a9d8dca
> To: <sip:18887776666 at 1xx.yy.zz.aa:5060>;tag=0a94b5e7
> CSeq: 102 INVITE
> Accept:  multipart/mixed, application/sdp, application/isup,
> application/dtmf, application/dtmf-relay
> Contact: <sip:18887776666 at 1xx.yy.zz.aa:32801>
> Allow:  OPTIONS, INVITE, CANCEL, ACK, BYE, INFO
> Content-Disposition: session; handling=required
> Content-Type: application/sdp
> Content-Length: 164
> 
> v=0
> o=Sonus_UAC 1383 25405 IN IP4 1xx.yy.zz.aa
> s=SIP Media Capabilities
> c=IN IP4 1xx.yy.zz.aa
> t=0 0
> m=audio 32836 RTP/AVP 0
> a=rtpmap:0 PCMU/8000
> a=sendrecv
> 
> Now, below, I see set_destination setting the destination port to 32801,
> but the next packet still sends to port 5060.
> 
> --- (12 headers 8 lines)---
> Found RTP audio format 0
> Peer audio RTP is at port 1xx.yy.zz.aa:32836
> Found description format PCMU
> Capabilities: us - 0x4 (ulaw), peer - audio=0x4 (ulaw)/video=0x0
> (nothing), combined - 0x4 (ulaw)
> Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x0
> (nothing), combined - 0x0 (nothing)
> list_route: hop: <sip:18887776666 at 1xx.yy.zz.aa:32801>
> set_destination: Parsing <sip:18887776666 at 1xx.yy.zz.aa:32801> for
> address/port to send to
> set_destination: set destination to 1xx.yy.zz.aa, port 32801
> Transmitting (NAT) to 1xx.yy.zz.aa:5060:
> ACK sip:18887776666 at 1xx.yy.zz.aa:32801 SIP/2.0
> Via: SIP/2.0/UDP 1aa.bbb.ccc.ddd:5060;branch=z9hG4bK29977c17;rport
> From: "+13115552368" <sip:+13115552368 at 1aa.bbb.ccc.ddd>;tag=as3a9d8dca
> To: <sip:18887776666 at 1xx.yy.zz.aa>;tag=0a94b5e7
> Contact: <sip:+13115552368 at 1aa.bbb.ccc.ddd>
> Call-ID: 64c034d2254d5edb7216047073e150c2 at 1aa.bbb.ccc.ddd
> CSeq: 102 ACK
> User-Agent: Asterisk PBX
> Max-Forwards: 70
> Content-Length: 0
> 
> Shouldn't this switch to talking to port 32801?
> 
> The sip.conf for this peer has nat=yes on it.
> [otherguy]
> type=friend
> host=1xx.yy.zz.aa
> context=otherguy
> disallow=all
> allow=ulaw
> insecure=very
> nat=yes
> 
> Have I found a bug?
> 
If you have NAT=yes, we will transmit to the port we receive from.
Transmitting (NAT) indicates that we have nat=yes and that basically
means "Ignore everything that the peer tells us and just reply back
to whoever sent us the information"

/O