[asterisk-users] On SIP INVITE answering to IP:port found in Contact: header.

[Matthew J. Roth]

Markus,

I'll take another shot at answering your questions.  As before, if someone more
knowledgeable, like Joshua Colp, also responds please give more credibility to
their remarks.

> Although I have to say I don't understand what is going on exactly. :) 
> As can be seen below, and as Joshua suggested, nat=no removed the 
> "rport" in the Via: header. I'm just wondering how Asterisk now knows to 
> which port to send the replies to? Is it simply using 5060 because 
> that's the RFC default for SIP? And because there is no port specified 
> in the Via: header?

I think you're on the right track here.  From RFC 3261 [1]:

   Before a request is sent, the client transport MUST insert a value of
   the "sent-by" field into the Via header field.  This field contains
   an IP address or host name, and port.  The usage of an FQDN is
   RECOMMENDED.  This field is used for sending responses under certain
   conditions, described below.  If the port is absent, the default
   value depends on the transport.  It is 5060 for UDP, TCP and SCTP,
   5061 for TLS.

> Would the nat=no switch also fix it in a scenario 
> where the remote side was sending from port 36252 but wanted the replies 
> on port 5061 instead of 5060?

Let's use another random port, 23456, as an example to avoid the default port
for TLS.  In this case, I believe the 'nat=no' setting would not work because if
a port isn't specified in the Via header the default port for UDP, 5060, is
used.  It would only work if the provider included the port in the Via header as
follows:

  Via: SIP/2.0/UDP 1.1.1.1:23456;branch=z9hG4bK2e91efaf

> Matthew, to provide you with feedback, here are the SIP headers before 
> and after nat=no:
> 
> Without nat=no:
> 
> IP 1.1.1.1.36252 > 2.2.2.2.5060: UDP, length 845
> INVITE sip:1234 at 2.2.2.2 SIP/2.0
> Via:SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKBroadWorks.2plg2e-2.2.2.2V5060-0-164693126-1529565735-1366128986378-
> From:<sip:9999 at 1.1.1.1;user=phone>;tag=1529565735-1366128986378-
> To:"My wife"<sip:1234 at 2.2.2.2:5060>
> Call-ID:BW161626378160413-1212022685 at 1.1.1.1
> CSeq:164693126 INVITE
> Contact:<sip:1.1.1.1:5060>
> Supported:100rel
> Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
> Accept:application/media_control+xml,application/sdp,multipart/mixed
> Max-Forwards:40
> Content-Type:application/sdp
> Content-Length:206
> 
> [ ... SDP removed ... ]
> 
> IP 2.2.2.2.5060 > 1.1.1.1.36252: UDP, length 602
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKBroadWorks.2plg2e-2.2.2.2V5060-0-164693126-1529565735-1366128986378-;received=1.1.1.1;rport=36252
> From: <sip:9999 at 1.1.1.1;user=phone>;tag=1529565735-1366128986378-
> To: "My wife"<sip:1234 at 2.2.2.2:5060>
> Call-ID: BW161626378160413-1212022685 at 1.1.1.1
> CSeq: 164693126 INVITE
> Server: Asterisk PBX 10.7.1
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
> Supported: replaces, timer
> Contact: <sip:1234 at 2.2.2.2:5060>
> Content-Length: 0

As Joshua Colp stated in another email [2], without 'nat=no' Asterisk forces
rport to be on by default.  From RFC 3581 [3]:

   The Session Initiation Protocol (SIP) operates over UDP and TCP,
   among others.  When used with UDP, responses to requests are returned
   to the source address the request came from, and to the port written
   into the topmost Via header field value of the request.  This
   behavior is not desirable in many cases, most notably, when the
   client is behind a Network Address Translator (NAT).  This extension
   defines a new parameter for the Via header field, called "rport",
   that allows a client to request that the server send the response
   back to the source IP address and port from which the request
   originated.

So Asterisk ignores the Via header in the INVITE, sends the response back to
1.1.1.1:36252 (the source IP address and port), and appends an rport parameter
to the Via header in the response.

> And with nat=no:
> 
> The same, except for the reply:
> 
> IP 2.2.2.2.5060 > 1.1.1.1.5060: UDP, length 588
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKBroadWorks.2plg2e-2.2.2.2V5060-0-179354203-809967599-1366158308532-;received=1.1.1.1
> 
> That means the "rport" part is gone.

The sample sip.conf for Asterisk 10 [4] has a comment stating:

  ; nat = no ; Use rport if the remote side says to use it.

Since the provider did not say to use rport in the INVITE, Asterisk responds
to the source address the request came from and to the port in the Via header.
The port is absent, so Asterisk uses the default port for UDP, 5060, and sends
the response back to 1.1.1.1:5060.

I really hope this helps you understand the situation.  I know I learned at
least a thing or two writing it up.

[1] http://www.ietf.org/rfc/rfc3261.txt
[2] http://lists.digium.com/pipermail/asterisk-users/2013-April/278611.html
[3] http://www.ietf.org/rfc/rfc3581.txt
[4] http://svnview.digium.com/svn/asterisk/branches/10/configs/sip.conf.sample?revision=373665&view=markup

Regards,

Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer