[Home]

Summary:ASTERISK-00726: [patch] parameters to Contact: header stripped off, breaks SNOM phone support
Reporter:Olle Johansson (oej)Labels:
Date Opened:2004-01-01 05:07:15.000-0600Date Closed:2008-01-15 15:06:07.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sipcontact.txt
Description:We at snom have problems with Asterisk when we receive calls without the
line indication. When we register we place a contact like this:

REGISTER sip:asterisk SIP/2.0
Contact: <sip:123@192.168.0.99;line=h35h345>

When we receive the 200 Ok, we search for the "h35h345". If we don&ASTERISK-7996;t find
it, we try to guess which line is affected. This is relatively easy on a
REGISTER response, but on an incoming INVITE we have serious problems. I
think some of the challenging and line-assignment problems are related to
this problem.

Strictly speaking, we register the contact
"sip:123@192.168.0.99;line=h35h345", NOT "sip:123@192.168.0.99"! Parameters
are an essential part of a URI which must not be discarded.

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

BTW the line-id has also the function of increasing the security
significantly. Just imaging a network script that sprays INVITE packets
through the network - the whole office would start ringing.

#!/bin/bash
# Give the colleagues a wake-up call!
i=1
while [ $i -lt 256 ]; do
 echo INVITE sip:192.168.0.$i SIP/2.0^M >junk.txt
 echo f: sip:whoever@is.stupid^M >>junk.txt
 echo t: sip:enough@to.accept^M >>junk.txt
 echo i: this@junk^M >>junk.txt
 echo l: 0^M >>junk.txt
 echo CSeq: 1 INVITE^M >>junk.txt
 echo ^M

>>>>junk.txt

 cat junk.txt >/dev/udp/192.168.0.$i/5060
 i=$[$i+1]
done

Unfortunately, the snom phones are not able to pick the right line on these
packets!

By requiring the line id, the phone would reject the INVITE as it can not
match the request URI with any valid line on the phone! BTW that&ASTERISK-7996;s why I
hate "direct IP calls" - it gives you zero security against such attacks.

Our latest image is 2.03e (http://snom.com/download/share), it does strict
line id comparison and tries to deal with "junk" line identifications as
good as possible.
Comments:By: Olle Johansson (oej) 2004-01-01 05:30:15.000-0600

Hmm. We save some information in the registry - but not the Contact: header. Due to NAT functions, it seems like asterisk rebuilds the contact header, not use the one sent verbatim.

Should we also save all ";" parameters and add them when sending invites?

By: stredicke (stredicke) 2004-01-03 09:18:35.000-0600

1. No, the line parameter is not specified anywhere (at least I don&ASTERISK-7996;t know). However, it's well in the scope of SIP, as the parameters are not interpreted by anyone but the issuing user agent. Therefore, you can put any junk in there. As far as I know, Pingtel also uses this method for identifying the line.

2. Well, if you do that you will have many problems. Probably most user agents try to deal with this somehow, but it's not according to the standard. When you say http://bla.com/page.htm?parameter=123 this is not the same as http://bla.com/page.htm!

For example, if a user agent registers as sip:123@yahoo.com and sip:123@google.com, and it receives a request URI for sip:123@local.ip.addr then how will it know who is being called? Looking at the To-Header is no answer, cause the call might re redirected.

Why make it so complicated? Just treat the URL as one string, no matter what is in there. Only when you have to make a routing decision, you need to take a look at the content.

BTW 2.03f is available at http://snom.com/download/share.

By: Olle Johansson (oej) 2004-01-03 10:32:48.000-0600

I guess you are meaning that Asterisk resolves the domain/realm into IP address and sends invite to IP address?
Hmm. Right. That's a problem.

So, if I understand you correctly, save everything in Contact: uri and use that to send Invite?

By: stredicke (stredicke) 2004-01-03 10:46:41.000-0600

Correct. If the contacts says <sip:bla@asterisk.org;parameter=123>;comment=lala copy the stuff between the < and > to the first line of the request (see RFC3261 for exact syntax for enclosing the URI):

INVITE sip:bla@asterisk.org;parameter=123 SIP/2.0

Most user agents put IP-addresses in the contact. So the first step should be simple.

But for example, when using GRUU, this is not the case any more. (I guess GRUU will play an important role in near future, see www.softarmor.com/sipwg/meets/ietf58/slides/pres-jdrosen-sip-gruu-ietf58.ppt). We are already using GRUU, when I call you from cs@snom.com, you will not see my IP address any more.

So you cant just send me an INVITE to my IP address any more!

I guess you get the point looking at my wake-the-office-up script...

CS

By: Olle Johansson (oej) 2004-01-03 11:02:58.000-0600

First patch, adds line back:

INVITE sip:ollesnom@213.204.186.40:63089;line=2 SIP/2.0
Via: SIP/2.0/UDP 213.204.186.39:5060;branch=z9hG4bK527e48a1
From: "Olle" <sip:asterisk@jarl.webway.se>;tag=as276c2ac6
To: <sip:ollesnom@213.204.186.40:63089;line=2>
Contact: <sip:asterisk@213.204.186.39>
Call-ID: 06fe78235106012052a66ad9223fcc9e@213.204.186.39
CSeq: 102 INVITE
User-Agent: Asterisk PBX (Asterisk.org)
Date: Sat, 03 Jan 2004 16:50:54 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 217

v=0
o=root 56717 56717 IN IP4 213.204.186.39
s=session
c=IN IP4 213.204.186.39
t=0 0
m=audio 11448 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

---
But still keeps IP address. I'll change to what you propose, to keep all of the contact uri.

By: Olle Johansson (oej) 2004-01-03 11:19:12.000-0600

But line 2 doesn't light up on the phone... Strange. Do I need to update?

Also note that Asterisk adds the NAT address to the Invite and contact. Not a good thing either, I guess. There's much cleaning up to do here. The From address is nothing you could use for answering...

By: stredicke (stredicke) 2004-01-03 11:59:20.000-0600

I think its better to move to 2.03f. We changed some stuff here and there, and its hard to predict how the previous version exactly reacts.

By: Olle Johansson (oej) 2004-01-07 02:16:48.000-0600

Ok, this bug also breaks support of some NAt boxes. We can't change the contact header, just got to keep it from registration.

By: Olle Johansson (oej) 2004-01-10 02:36:30.000-0600

Please test chan_sip2.c - the new version -where I have changed the way we handle Contact: headers.

See bug 0000759

By: ww (ww) 2004-01-12 20:45:15.000-0600

it appears that parse_contact() in chan_sip.c
discards everything after the ;
perhaps this can be fixed relatively easily...

By: Olle Johansson (oej) 2004-03-21 08:38:11.000-0600

I think that chan_sip2 solves this problem, but need confirmation from others. Please test chan_sip2 in bug 759 and confirm if it works for you or not. If it works, we'll create a patch for chan_sip and move it forward.

I basically (on Christians suggestion) save the Contact: header from registration and use that for outbound calls to the peer. If you do not use registration, ASterisk will create a contact header and use that.

By: Olle Johansson (oej) 2004-03-21 17:34:30.000-0600

Please check if the patch in 777 helps SNOM phones. I need feedback!

By: Olle Johansson (oej) 2004-03-22 06:17:12.000-0600

Christian: Is there anything in the RFC that says "don't touch the Contact: header" ?

Need ammo :-)

By: Olle Johansson (oej) 2004-03-22 10:09:12.000-0600

Closing this and move discussion to bug # 777 - the same topic. Stay tuned on a new channel :-)

By: Olle Johansson (oej) 2004-08-24 07:49:50

Reopening this bug

By: Olle Johansson (oej) 2004-08-24 07:50:25

Added patch to fix contact: header problems at registration and subsequent INVITE.

By: Mark Spencer (markster) 2004-08-30 01:18:47

Okay, try latest CVS, I've got my own strategy i threw in but i have no way to test it at the moment.

By: Olle Johansson (oej) 2004-08-30 02:38:24

Markster, your patch still doesn't help us... The INVITE is still addressed as

INVITE peername@ipadress SIP/2.0

I don't see the extraparams that is indeed saved when doing a "sip show peer".

Quoting Stredicke (above):
"Why make it so complicated? Just treat the URL as one string, no matter what is in there. Only when you have to make a routing decision, you need to take a look at the content."

We should not send anything else than the text used in REGISTER.

By: Mark Spencer (markster) 2004-08-30 09:47:22

Well let me ssh in and look then.

By: Mark Spencer (markster) 2004-08-31 10:20:45

Can you find me on IRC so I can look at this on your system  please.  thanks.

By: Mark Spencer (markster) 2004-08-31 13:36:30

Fixed in CVS

By: Digium Subversion (svnbot) 2008-01-15 15:06:07.000-0600

Repository: asterisk
Revision: 3680

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r3680 | markster | 2008-01-15 15:06:07 -0600 (Tue, 15 Jan 2008) | 2 lines

Track extra parameters in contact (bug ASTERISK-726)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=3680