[Asterisk-Dev] Help required follow me feature

sthiti sthiti at adyasystems.com
Sun Jul 25 21:24:37 MST 2004


HI,

Please anyone help me to configure the follow me feature?

Sthiti Ranjan Sarangi
Adyasystems & Software Pvt. Ltd
New Delhi
India

-----Original Message-----
From: asterisk-dev-admin at lists.digium.com
[mailto:asterisk-dev-admin at lists.digium.com] On Behalf Of
asterisk-dev-request at lists.digium.com
Sent: Friday, July 23, 2004 4:34 AM
To: asterisk-dev at lists.digium.com
Subject: Asterisk-Dev digest, Vol 1 #784 - 8 msgs


Send Asterisk-Dev mailing list submissions to
	asterisk-dev at lists.digium.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.digium.com/mailman/listinfo/asterisk-dev
or, via email, send a message with subject or body 'help' to
	asterisk-dev-request at lists.digium.com

You can reach the person managing the list at
	asterisk-dev-admin at lists.digium.com

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Asterisk-Dev digest..."


Today's Topics:

   1. Authorization header not formatted properly when REGISTER msg is
challenged (algorithm=MD5) (Michael Lunsford)
   2. RE: Re: Asterisk Book Reviewer (asterisk at packtpub.com)
   3. RE: Re: Asterisk Book Reviewer (asterisk at packtpub.com)
   4. Re: Authorization header not formatted properly when
       REGISTER msg is challenged (algorithm=MD5) (Olle E. Johansson)
   5. Re: UK Caller ID patch and new CVS (dking at pimpsoft.com)
   6. RE: UK Caller ID patch and new CVS (dking at pimpsoft.com)
   7. Re: Authorization header not formatted properly when REGISTER msg
is challenged (algorithm=MD5) (Rob Gagnon)

--__--__--

Message: 1
Date: Thu, 22 Jul 2004 15:55:25 -0400
From: "Michael Lunsford" <michael.lunsford at cbeyond.net>
To: <asterisk-dev at lists.digium.com>
Subject: [Asterisk-Dev] Authorization header not formatted properly when
REGISTER msg is challenged (algorithm=MD5)
Reply-To: asterisk-dev at lists.digium.com

I am new to this forum and am looking for some help on an issue I'm
having with the Asterisk. The company I work for has Cisco BTS 10200s
deployed in several Tier 1 cities through the US with over 13,000
customers to date. Our engineering team is performing interoperability
testing between the Asterisk and the Cisco's BTS 10200 softswitch and
have found an issue.

With our switch configured to authorize the registration from Asterisk,
the Asterisks responds to the challenge (401 Unauthorized) with an error
in the REGISTER message. The authorization header in the REGISTER msg
from the Asterisk contains 'algorithm=3D"MD5"'. The quote around the MD5
are not per spec in RFC 2617 3.2.1
(http://www.ietf.org/rfc/rfc2617.txt).  Section 3.2.2 "The Authorization
Request Header" describes the response a User Agent takes when
challenged with a "401 Unauthorized". It refers section 3.2.1 "The
WWW-Authenticate Response Header" for the framework of the construction
of the message. Referring to 3.2.1, we see that everything that is
supposed to be quoted in the message states either "quoted-string" or
has <"> to indicate that the quotes are supposed to be in the message.
The quotes around the MD5 are not to be included in the message.

In the source, I removed the quotes so that the authorization header in
the REGISTER message now read 'algorithm=3DMD5' instead of
'algorithm=3D"MD5"'. The BTS 10200 now accepts the message and sends a =
200 OK.

Please let me know your thoughts. I am registered to the bug reporting
site but wanted to query and see if others were in agreement with my
interpretation of the spec.

Thanks,
Michael

Immediately below is the SIP debug of the successful call sequence with
the quotes removed around MD5.  Below that is the unsucessful
registration when the quotes are sent.

#############################################################
SIP debug for successful call registration after I have removed the
quotes from around the MD5 in the authorization header.

*CLI> sip reload
 Reloading SIP
  =3D=3D Parsing '/etc/asterisk/sip.conf': Found
11 headers, 0 lines
Reliably Transmitting:
REGISTER sip:sia-lab2ca102.lab2.cbeyond.net SIP/2.0
Via: SIP/2.0/UDP 90.1.1.202:5060;branch=3Dz9hG4bK15eef8b1
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=3Das64e78660
To: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>
Call-ID: 6f264ca6263293f5400ccaa527dce06d at 90.1.1.202
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Expires: 3600
Contact: <sip:4000 at 90.1.1.202>
Event: registration
Content-Length: 0

 (no NAT) to 90.0.4.12:5060


Sip read:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
90.1.1.202:5060;branch=3Dz9hG4bK15eef8b1;received=3D90.1.1.202
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=3Das64e78660
To:
<sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=3D1_1102_t9670_537e
Call-ID: 6f264ca6263293f5400ccaa527dce06d at 90.1.1.202
CSeq: 102 REGISTER
WWW-Authenticate: Digest realm=3D"customer10.lab2.cbeyond.net",
nonce=3D"6e2db394cb0ab7851d44d5472b1dac27", algorithm=3DMD5, =
qop=3D"auth"
Content-Length: 0


8 headers, 0 lines
12 headers, 0 lines
Reliably Transmitting:
REGISTER sip:sia-lab2ca102.lab2.cbeyond.net SIP/2.0
Via: SIP/2.0/UDP 90.1.1.202:5060;branch=3Dz9hG4bK67fcb845
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=3Das64e78660
To: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>
Call-ID: 6f264ca6263293f5400ccaa527dce06d at 90.1.1.202
CSeq: 103 REGISTER
User-Agent: Asterisk PBX
Authorization: Digest username=3D"6783979900",
realm=3D"customer10.lab2.cbeyond.net", algorithm=3DMD5,
uri=3D"sip:sia-lab2ca102.lab2.cbeyond.net",
nonce=3D"6e2db394cb0ab7851d44d5472b1dac27",
response=3D"549eb04688dcea6195e24fb1de1d41d0", opaque=3D"", =
qop=3D"auth", cnonce=3D"795cdc3e", nc=3D00000001
Expires: 3600
Contact: <sip:4000 at 90.1.1.202>
Event: registration
Content-Length: 0

 (no NAT) to 90.0.4.12:5060


Sip read:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
90.1.1.202:5060;branch=3Dz9hG4bK67fcb845;received=3D90.1.1.202
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=3Das64e78660
To:
<sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=3D1_1102_t9670_537e
Call-ID: 6f264ca6263293f5400ccaa527dce06d at 90.1.1.202
CSeq: 103 REGISTER
Date: Thu, 22 Jul 2004 19:41:54 GMT
Contact: <sip:4000 at 90.1.1.20>;expires=3D1226,
<sip:4000 at 90.1.1.202>;expires=3D3600
Authentication-Info: qop=3D"auth",
rspauth=3D"8369aa16a70f6bef295a0366fcd3b2de", cnonce=3D"795cdc3e",
nc=3D00000001
Content-Length: 0


10 headers, 0 lines


####################################################
Below is sip debug for unsuccessful registration when Asterisk sends
'algorithm=3D"MD5"'


*CLI> sip reload
 Reloading SIP
  =3D=3D Parsing '/etc/asterisk/sip.conf': Found
11 headers, 0 lines
Reliably Transmitting:
REGISTER sip:sia-lab2ca102.lab2.cbeyond.net SIP/2.0
Via: SIP/2.0/UDP 90.1.1.202:5060;branch=3Dz9hG4bK4269b1ab
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=3Das034fa66d
To: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>
Call-ID: 56ecb3a6001b35192b5ee19d4138fe81 at 90.1.1.202
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Expires: 3600
Contact: <sip:4000 at 90.1.1.202>
Event: registration
Content-Length: 0

 (no NAT) to 90.0.4.12:5060


Sip read:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
90.1.1.202:5060;branch=3Dz9hG4bK4269b1ab;received=3D90.1.1.202
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=3Das034fa66d
To:
<sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=3D1_1102_t9680_1y9b
Call-ID: 56ecb3a6001b35192b5ee19d4138fe81 at 90.1.1.202
CSeq: 102 REGISTER
WWW-Authenticate: Digest realm=3D"customer10.lab2.cbeyond.net",
nonce=3D"f6576068a2173d58e60f282deb3d3bd5", algorithm=3DMD5, =
qop=3D"auth"
Content-Length: 0


8 headers, 0 lines
12 headers, 0 lines
Reliably Transmitting:
REGISTER sip:sia-lab2ca102.lab2.cbeyond.net SIP/2.0
Via: SIP/2.0/UDP 90.1.1.202:5060;branch=3Dz9hG4bK7e9b8de5
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=3Das034fa66d
To: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>
Call-ID: 56ecb3a6001b35192b5ee19d4138fe81 at 90.1.1.202
CSeq: 103 REGISTER
User-Agent: Asterisk PBX
Authorization: Digest username=3D"6783979900",
realm=3D"customer10.lab2.cbeyond.net", algorithm=3D"MD5",
uri=3D"sip:sia-lab2ca102.lab2.cbeyond.net",
nonce=3D"f6576068a2173d58e60f282deb3d3bd5",
response=3D"5840d28faf5e5ed95d0fceda4711bd7b", opaque=3D"", =
qop=3D"auth", cnonce=3D"655123e8", nc=3D00000001
Expires: 3600
Contact: <sip:4000 at 90.1.1.202>
Event: registration
Content-Length: 0

 (no NAT) to 90.0.4.12:5060


Sip read:
SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP
90.1.1.202:5060;branch=3Dz9hG4bK7e9b8de5;received=3D90.1.1.202
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=3Das034fa66d
To: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>
Call-ID: 56ecb3a6001b35192b5ee19d4138fe81 at 90.1.1.202
CSeq: 103 REGISTER
Content-Length: 0


7 headers, 0 lines
    -- Got SIP response 400 "Bad Request" back from 90.0.4.12 Destroying
call '56ecb3a6001b35192b5ee19d4138fe81 at 90.1.1.202'

--__--__--

Message: 2
Date: Thu, 22 Jul 2004 21:47:19 +0100 (BST)
Subject: RE: [Asterisk-Dev] Re: Asterisk Book Reviewer
From: asterisk at packtpub.com
To: asterisk-dev at lists.digium.com
Reply-To: asterisk-dev at lists.digium.com

I explained what roles David Maclean and I had at PI, and the
authorities those roles had, because most of those who read previous
messages did not know that, as was clear from one of the replies. I
reported facts. What you make of them is up to you. I am not going to
argue with anyone the conclusions they draw from those facts.

I contacted a number of people in the Asterisk community recently and in
the past about our Asterisk book. All of them were contacted using my
email address. I am using asterisk at packtpub.com because one of our
public email addresses has already received an abusive message triggered
by earlier messages that were posted on this list. I am not keen on
getting more of these sent to my email address. Using special email
addresses for public forums is a common and effective method to control
spam. If you want to make even this practice proof of ill intention,
then I have nothing more to say to convince you otherwise. Again, I did
not post to this list to discuss conclusions and manipulate
interpretations, but to respond to untrue claims.

I posted to this forum because one of the people that I contacted about
our Asterisk book chose instead of checking with me first the claims he
read in a blog article to post the link to the article to the list. I
asked that person to post my reply to him to this forum on my behalf,
but he suggested that I should do that. I am not an Asterisk developer,
and I did not want to have to subscribe to the list to send messages
that are clearly not what this forum was designed for.

I hope that this is my last message to this forum about this subject. My
intention was to respond to untrue allegations by stating facts, and I
have done that. I will not take part in discussing what people make of
those facts. The only thing that could force me to write again about
this issue is posting serious and misleading allegations that I have not
already addressed. I sincerely hope that I will not have to do that.

If anyone is interested in asking me about anything, they are welcome to
write to me at asterisk-dev at lists.digium.com. I will try my best to
answer all questions, and I will use my other email address in doing so.

My apologies for those who had no interest in my messages, and my thanks
to those who read them.

Thanks.

Louay




> It doesn't matter who or what connection he has with that company. The

> fact of the matter is he was directly linked with a company that 
> cheated people out of money and is thus guilty by association. In the 
> same way you can not prove outright that we can not prove he is 
> responsible for this you can not prove that you are not.
>
> The only way to get people to trust anyone with knowledge of this is 
> for the parent company to do the right thing, anything else can only 
> be seen as a attempt to get good public relations, just like how your 
> company set up a email address just for contacting this list; if you 
> really wanted to do the right thing and be in good with the public you

> would not be actively trying to circumvent outside communication, for 
> example.
>


--__--__--

Message: 3
Date: Thu, 22 Jul 2004 22:10:23 +0100 (BST)
Subject: RE: [Asterisk-Dev] Re: Asterisk Book Reviewer
From: asterisk at packtpub.com
To: asterisk-dev at lists.digium.com
Reply-To: asterisk-dev at lists.digium.com

I meant to say people can contact me at asterisk at packtpub.com, not
asterisk-dev at lists.digium.com. My apology.


Louay

> I explained what roles David Maclean and I had at PI, and the 
> authorities those roles had, because most of those who read previous 
> messages did not know that, as was clear from one of the replies. I 
> reported facts. What you make of them is up to you. I am not going to 
> argue with anyone the conclusions they draw from those facts.
>
> I contacted a number of people in the Asterisk community recently and 
> in the past about our Asterisk book. All of them were contacted using 
> my email address. I am using asterisk at packtpub.com because one of our 
> public email addresses has already received an abusive message 
> triggered by earlier messages that were posted on this list. I am not 
> keen on getting more of these sent to my email address. Using special 
> email addresses for public forums is a common and effective method to 
> control spam. If you want to make even this practice proof of ill 
> intention, then I have nothing more to say to convince you otherwise. 
> Again, I did not post to this list to discuss conclusions and 
> manipulate interpretations, but to respond to untrue claims.
>
> I posted to this forum because one of the people that I contacted 
> about our Asterisk book chose instead of checking with me first the 
> claims he read in a blog article to post the link to the article to 
> the list. I asked that person to post my reply to him to this forum on

> my behalf, but he suggested that I should do that. I am not an 
> Asterisk developer, and I did not want to have to subscribe to the 
> list to send messages that are clearly not what this forum was 
> designed for.
>
> I hope that this is my last message to this forum about this subject. 
> My intention was to respond to untrue allegations by stating facts, 
> and I have done that. I will not take part in discussing what people 
> make of those facts. The only thing that could force me to write again

> about this issue is posting serious and misleading allegations that I 
> have not already addressed. I sincerely hope that I will not have to 
> do that.
>
> If anyone is interested in asking me about anything, they are welcome 
> to write to me at asterisk-dev at lists.digium.com. I will try my best to

> answer all questions, and I will use my other email address in doing 
> so.
>
> My apologies for those who had no interest in my messages, and my 
> thanks to those who read them.
>
> Thanks.
>
> Louay
>
>
>
>
>> It doesn't matter who or what connection he has with that company. 
>> The fact of the matter is he was directly linked with a company that 
>> cheated people out of money and is thus guilty by association. In the

>> same way you can not prove outright that we can not prove he is 
>> responsible for this you can not prove that you are not.
>>
>> The only way to get people to trust anyone with knowledge of this is 
>> for the parent company to do the right thing, anything else can only 
>> be seen as a attempt to get good public relations, just like how your

>> company set up a email address just for contacting this list; if you 
>> really wanted to
>> do the right thing and be in good with the public you would not be
>> actively trying to circumvent outside communication, for example.
>>
>
>


--__--__--

Message: 4
Date: Thu, 22 Jul 2004 23:23:59 +0200
From: "Olle E. Johansson" <oej at edvina.net>
Organization: Edvina AB
To: asterisk-dev at lists.digium.com
Subject: Re: [Asterisk-Dev] Authorization header not formatted properly
when  REGISTER msg is challenged (algorithm=MD5)
Reply-To: asterisk-dev at lists.digium.com

Michael Lunsford wrote:

> I am new to this forum and am looking for some help on an issue I'm 
> having with the Asterisk. The company I work for has Cisco BTS 10200s 
> deployed in several Tier 1 cities through the US with over 13,000 
> customers to date. Our engineering team is performing interoperability

> testing between the Asterisk and the Cisco's BTS 10200 softswitch and 
> have found an issue.
> 
> With our switch configured to authorize the registration from 
> Asterisk, the Asterisks responds to the challenge (401 Unauthorized) 
> with an error in the REGISTER message. The authorization header in the

> REGISTER msg from the Asterisk contains 'algorithm="MD5"'. The quote 
> around the MD5 are not per spec in RFC 2617 3.2.1 
> (http://www.ietf.org/rfc/rfc2617.txt).  Section 3.2.2 "The 
> Authorization Request Header" describes the response a User Agent 
> takes when challenged with a "401 Unauthorized". It refers section 
> 3.2.1 "The WWW-Authenticate Response Header" for the framework of the 
> construction of the message. Referring to 3.2.1, we see that 
> everything that is supposed to be quoted in the message states either 
> "quoted-string" or has <"> to indicate that the quotes are supposed to

> be in the message. The quotes around the MD5 are not to be included in

> the message.
> 
> In the source, I removed the quotes so that the authorization header 
> in the REGISTER message now read 'algorithm=MD5' instead of 
> 'algorithm="MD5"'. The BTS 10200 now accepts the message and sends a 
> 200 OK.
> 
You are right. This needs to be changed. Open a bug in bugs.digium.com
RFC3261 examples clearly have algorithm=MD5 without quotes.

/Olle

--__--__--

Message: 5
From: dking at pimpsoft.com
Organization: pimpsoft.com
To: asterisk-dev at lists.digium.com
Date: Thu, 22 Jul 2004 14:49:43 -0700
Subject: Re: [Asterisk-Dev] UK Caller ID patch and new CVS
Reply-To: asterisk-dev at lists.digium.com

Yes I have.

The main problem I have is that if a patch can make things working in 
the short terms then why not add it? If a more elegant solution is 
found weeks later that patch can simply be taken out, either way the 
problem is solved,and  people are happy since the software 'just 
works' while digium gains a larger customer base since the hardware 
now works as expected and more people can then buy the hardware and 
use it.

I'm not even in the UK so that patch will not even help me at all, 
but I still think it a good idea; That has to say something.


On 22 Jul 2004 at 11:51, Richard Lyman wrote:

> it's obvious you never attempted to get a patch in the linux
> kernel source!  someone HAS to 'govern' the code, else it's just 
> a pile of spagetti.
> 
> dking at pimpsoft.com wrote:
> 
> > The true nature of open source is defined as the source being 
> > availabl=
e and open. Limiting the included code for the central offering based on
s= omeone=92s will because he thinks it will mean he can sell more
hardware i= f he does not do so is not open source, its dictatorship. I
find it very s= ad that based on my understanding asterisk will not
include code that will=  help many people just because one person feels
that to do so would hurt h= is companies profit margins, when the code
is no doubt already available 
> > somewhere else or is needed by someone.
> > 
> > In the time I have watched this list even before I started posting I

> > h=
ave seen much of this; Keep up the dictatorship of the central code
reposi= tory and I guarantee you a branch of the source code will form
within the = next 3-6 months. Not by me since I do not have the
requisite understanding= , but I believe it important to say here that
if the open source community=  does not like the way digium or
=91Mark=92 is doing things it will simply=  make them unnecessary for
the project to go forward by cutting them out o= f 
the 
> > loop. And that perfectly acceptable from a legal standpoint since 
> > aste=
risk is after all GPL.
> > 
> > I don=92t mean to be cruel or annoying, I=92m stating facts as I see

> > t=
hem. If I am wrong or ignorant by all means tell me, but if it looks
like = this to me, how do you think it looks to the thousands of other
people gho= sting around this project and watching in the shadows as I
once did?
> > 
> > Just a though.
> > 
> > On 22 Jul 2004 at 14:43, Chris Stenton wrote:
> > 
> > 
> >>Mark does not like the history buffer method  used. I think code 
> >>will =
be
> >>included for the the fxo module at some point but not for the X100P.
> >>
> >>Chris.
> >>
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Asterisk-Dev mailing list
> > Asterisk-Dev at lists.digium.com 
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-dev
> > 
> 
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com 
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 





--__--__--

Message: 6
From: dking at pimpsoft.com
Organization: pimpsoft.com
To: asterisk-dev at lists.digium.com
Date: Thu, 22 Jul 2004 14:56:39 -0700
Subject: RE: [Asterisk-Dev] UK Caller ID patch and new CVS
Reply-To: asterisk-dev at lists.digium.com

Maybe I am hearing it wrong, but it is my understanding that the code 
used to fix the problem as well as the needed hardware driver for the 
FXO card will not be included in the cvs, and the people at digum are 
just sitting on it.

Is that correct?

On 22 Jul 2004 at 12:42, Gilmore, Gerry wrote:

> So which source is not available?
> 
> -- There are 10 kinds of people in the world, those who understand 
> binary and those who don't.
>  
> Gerry Gilmore
> Field Applications Engineer
> Communications Sales Organization
> Intel Corporation
> http://www.intel.com
>  
> 
> 
> -----Original Message-----
> From: asterisk-dev-admin at lists.digium.com
> [mailto:asterisk-dev-admin at lists.digium.com] On Behalf Of 
> dking at pimpsoft.com
> Sent: Thursday, July 22, 2004 2:21 PM
> To: asterisk-dev at lists.digium.com
> Subject: Re: [Asterisk-Dev] UK Caller ID patch and new CVS
> 
> 
> The true nature of open source is defined as the source being 
> available and open. Limiting the included code for the central 
> offering based on someone's will because he thinks it will mean he can

> sell more hardware if he does not do so is not open source, its 
> dictatorship. I find it very sad that based on my understanding 
> asterisk will not include code that will help many people just because

> one person feels that to do so would hurt his companies profit 
> margins, when the code is no doubt already available somewhere else or

> is needed by someone.
> 
> In the time I have watched this list even before I started posting I 
> have seen much of this; Keep up the dictatorship of the central code 
> repository and I guarantee you a branch of the source code will form 
> within the next 3-6 months. Not by me since I do not have the 
> requisite understanding, but I believe it important to say here that 
> if the open source community does not like the way digium or 'Mark' is

> doing things it will simply make them unnecessary for the project to 
> go forward by cutting them out of the loop. And that perfectly 
> acceptable from a legal standpoint since asterisk is after all GPL.
> 
> I don't mean to be cruel or annoying, I'm stating facts as I see them.

> If I am wrong or ignorant by all means tell me, but if it looks like 
> this to me, how do you think it looks to the thousands of other people

> ghosting around this project and watching in the shadows as I once 
> did?
> 
> Just a though.
> 
> On 22 Jul 2004 at 14:43, Chris Stenton wrote:
> 
> > Mark does not like the history buffer method  used. I think code 
> > will
> be
> > included for the the fxo module at some point but not for the X100P.
> > 
> > Chris.
> > 
> 
> 
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com 
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com 
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 





--__--__--

Message: 7
From: "Rob Gagnon" <rob at networkip.net>
To: <asterisk-dev at lists.digium.com>
Subject: Re: [Asterisk-Dev] Authorization header not formatted properly
when REGISTER msg is challenged (algorithm=MD5)
Date: Thu, 22 Jul 2004 17:47:00 -0500
Organization: Network IP
Reply-To: asterisk-dev at lists.digium.com

This is interesting....  You obviously are right, in that the quotes fix
your problem.  The issue seems to stem from an inconsistency in
RFC3261...

Sections 20.27, and 20.44 show examples with the MD5 without quotes:
   Example:
      Proxy-Authenticate: Digest realm="atlanta.com",
      domain="sip:ss1.carrier.com", qop="auth",
      nonce="f84f1cec41e6cbe5aea9c8e88d359",
      opaque="", stale=FALSE, algorithm=MD5

Now, in Section 25.1 (Basic Rules), the value for "algorithm" is shown
to apparently require the quotes:
   algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / token )

So... I would think the solution, for now, is to make this configurable.
I would imagine there are some devices that require the quotes, some
that do not want it, and some that don't care.

Until the RFC is cleared up, or Cisco modifies their IOS to support
either quoted, or un-quoted values, I don't see much else you can do.

Rob

----- Original Message ----- 
From: "Michael Lunsford" <michael.lunsford at cbeyond.net>
To: <asterisk-dev at lists.digium.com>
Sent: Thursday, July 22, 2004 2:55 PM
Subject: [Asterisk-Dev] Authorization header not formatted properly when
REGISTER msg is challenged (algorithm=MD5)


I am new to this forum and am looking for some help on an issue I'm
having with the Asterisk. The company I work for has Cisco BTS 10200s
deployed in several Tier 1 cities through the US with over 13,000
customers to date. Our engineering team is performing interoperability
testing between the Asterisk and the Cisco's BTS 10200 softswitch and
have found an issue.

With our switch configured to authorize the registration from Asterisk,
the Asterisks responds to the challenge (401 Unauthorized) with an error
in the REGISTER message. The authorization header in the REGISTER msg
from the Asterisk contains 'algorithm="MD5"'. The quote around the MD5
are not per spec in RFC 2617 3.2.1
(http://www.ietf.org/rfc/rfc2617.txt).  Section 3.2.2 "The Authorization
Request Header" describes the response a User Agent takes when
challenged with a "401 Unauthorized". It refers section 3.2.1 "The
WWW-Authenticate Response Header" for the framework of the construction
of the message. Referring to 3.2.1, we see that everything that is
supposed to be quoted in the message states either "quoted-string" or
has <"> to indicate that the quotes are supposed to be in the message.
The quotes around the MD5 are not to be included in the message.

In the source, I removed the quotes so that the authorization header in
the REGISTER message now read 'algorithm=MD5' instead of
'algorithm="MD5"'. The BTS 10200 now accepts the message and sends a 200
OK.

Please let me know your thoughts. I am registered to the bug reporting
site but wanted to query and see if others were in agreement with my
interpretation of the spec.

Thanks,
Michael

Immediately below is the SIP debug of the successful call sequence with
the quotes removed around MD5.  Below that is the unsucessful
registration when the quotes are sent.

#############################################################
SIP debug for successful call registration after I have removed the
quotes from around the MD5 in the authorization header.

*CLI> sip reload
 Reloading SIP
  == Parsing '/etc/asterisk/sip.conf': Found
11 headers, 0 lines
Reliably Transmitting:
REGISTER sip:sia-lab2ca102.lab2.cbeyond.net SIP/2.0
Via: SIP/2.0/UDP 90.1.1.202:5060;branch=z9hG4bK15eef8b1
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=as64e78660
To: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>
Call-ID: 6f264ca6263293f5400ccaa527dce06d at 90.1.1.202
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Expires: 3600
Contact: <sip:4000 at 90.1.1.202>
Event: registration
Content-Length: 0

 (no NAT) to 90.0.4.12:5060


Sip read:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
90.1.1.202:5060;branch=z9hG4bK15eef8b1;received=90.1.1.202
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=as64e78660
To:
<sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=1_1102_t9670_537e
Call-ID: 6f264ca6263293f5400ccaa527dce06d at 90.1.1.202
CSeq: 102 REGISTER
WWW-Authenticate: Digest realm="customer10.lab2.cbeyond.net",
nonce="6e2db394cb0ab7851d44d5472b1dac27", algorithm=MD5, qop="auth"
Content-Length: 0


8 headers, 0 lines
12 headers, 0 lines
Reliably Transmitting:
REGISTER sip:sia-lab2ca102.lab2.cbeyond.net SIP/2.0
Via: SIP/2.0/UDP 90.1.1.202:5060;branch=z9hG4bK67fcb845
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=as64e78660
To: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>
Call-ID: 6f264ca6263293f5400ccaa527dce06d at 90.1.1.202
CSeq: 103 REGISTER
User-Agent: Asterisk PBX
Authorization: Digest username="6783979900",
realm="customer10.lab2.cbeyond.net", algorithm=MD5,
uri="sip:sia-lab2ca102.lab2.cbeyond.net",
nonce="6e2db394cb0ab7851d44d5472b1dac27",
response="549eb04688dcea6195e24fb1de1d41d0", opaque="", qop="auth",
cnonce="795cdc3e", nc=00000001
Expires: 3600
Contact: <sip:4000 at 90.1.1.202>
Event: registration
Content-Length: 0

 (no NAT) to 90.0.4.12:5060


Sip read:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
90.1.1.202:5060;branch=z9hG4bK67fcb845;received=90.1.1.202
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=as64e78660
To:
<sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=1_1102_t9670_537e
Call-ID: 6f264ca6263293f5400ccaa527dce06d at 90.1.1.202
CSeq: 103 REGISTER
Date: Thu, 22 Jul 2004 19:41:54 GMT
Contact: <sip:4000 at 90.1.1.20>;expires=1226,
<sip:4000 at 90.1.1.202>;expires=3600
Authentication-Info: qop="auth",
rspauth="8369aa16a70f6bef295a0366fcd3b2de", cnonce="795cdc3e",
nc=00000001
Content-Length: 0


10 headers, 0 lines


####################################################
Below is sip debug for unsuccessful registration when Asterisk sends
'algorithm="MD5"'


*CLI> sip reload
 Reloading SIP
  == Parsing '/etc/asterisk/sip.conf': Found
11 headers, 0 lines
Reliably Transmitting:
REGISTER sip:sia-lab2ca102.lab2.cbeyond.net SIP/2.0
Via: SIP/2.0/UDP 90.1.1.202:5060;branch=z9hG4bK4269b1ab
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=as034fa66d
To: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>
Call-ID: 56ecb3a6001b35192b5ee19d4138fe81 at 90.1.1.202
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Expires: 3600
Contact: <sip:4000 at 90.1.1.202>
Event: registration
Content-Length: 0

 (no NAT) to 90.0.4.12:5060


Sip read:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
90.1.1.202:5060;branch=z9hG4bK4269b1ab;received=90.1.1.202
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=as034fa66d
To:
<sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=1_1102_t9680_1y9b
Call-ID: 56ecb3a6001b35192b5ee19d4138fe81 at 90.1.1.202
CSeq: 102 REGISTER
WWW-Authenticate: Digest realm="customer10.lab2.cbeyond.net",
nonce="f6576068a2173d58e60f282deb3d3bd5", algorithm=MD5, qop="auth"
Content-Length: 0


8 headers, 0 lines
12 headers, 0 lines
Reliably Transmitting:
REGISTER sip:sia-lab2ca102.lab2.cbeyond.net SIP/2.0
Via: SIP/2.0/UDP 90.1.1.202:5060;branch=z9hG4bK7e9b8de5
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=as034fa66d
To: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>
Call-ID: 56ecb3a6001b35192b5ee19d4138fe81 at 90.1.1.202
CSeq: 103 REGISTER
User-Agent: Asterisk PBX
Authorization: Digest username="6783979900",
realm="customer10.lab2.cbeyond.net", algorithm="MD5",
uri="sip:sia-lab2ca102.lab2.cbeyond.net",
nonce="f6576068a2173d58e60f282deb3d3bd5",
response="5840d28faf5e5ed95d0fceda4711bd7b", opaque="", qop="auth",
cnonce="655123e8", nc=00000001
Expires: 3600
Contact: <sip:4000 at 90.1.1.202>
Event: registration
Content-Length: 0

 (no NAT) to 90.0.4.12:5060


Sip read:
SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP
90.1.1.202:5060;branch=z9hG4bK7e9b8de5;received=90.1.1.202
From: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>;tag=as034fa66d
To: <sip:6783979900 at sia-lab2ca102.lab2.cbeyond.net>
Call-ID: 56ecb3a6001b35192b5ee19d4138fe81 at 90.1.1.202
CSeq: 103 REGISTER
Content-Length: 0


7 headers, 0 lines
    -- Got SIP response 400 "Bad Request" back from 90.0.4.12 Destroying
call '56ecb3a6001b35192b5ee19d4138fe81 at 90.1.1.202'
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev



--__--__--

_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev


End of Asterisk-Dev Digest




More information about the asterisk-dev mailing list