Summary:ASTERISK-05599: * Sends 403 Unauthorized upon reception of INFO method from a Nortel MCS 5200 sip proxy
Reporter:Chandi Bernier (chandi)Labels:
Date Opened:2005-11-14 12:59:46.000-0600Date Closed:2007-11-02 15:20:53
Versions:Frequency of
Environment:Attachments:( 0) ast-mcs500.patch
( 1) infofix-81430-1.patch
Description:The Nortel sip proxy sends an INFO packet every 6-10 minutes and Asterisk seems not to know what to do with it and replies "403 Unauthorized" instead of "200 OK" to it. Then the sip proxy still waits 30 seconds for a "200 OK" and then Hangup the call.

While the sip proxy waits for it's timeout to finish, it sends again a few INFO packets which asterisk answers by a "200 OK" but that doesn't make the sip proxy happy.

Here is the sip logs starting from the first INFO which is instantly answered by asterisk with a 403 Unauthorized.


****** STEPS TO REPRODUCE ******

You need to be able to use a Nortel MCS 5200 sip proxy to reproduce it


Comments:By: Olle Johansson (oej) 2005-11-14 13:34:02.000-0600

I need to see more - is this INFO part of an existing SIP dialog or outside of a dialog? What's the actual meaning of this packet? We can't really blindly answer 200 OK to something we do not understand...

Any pointers to documentation on this packet would be appreciated.



INFO sip:sip-username@ SIP/2.0
t: "John Doe" <sip:sip-username@nortel-sip-proxy.com>;screen=yes;privacy=full;party=calling
f: <sip:15147552426@nortel-sip-proxy.com>;tag=6386023631964272569
i: 2e6a63247574f71a2d20d4ab75f98680@nortel-sip-proxy.com
CSeq: 98993 INFO
v: SIP/2.0/UDP;branch=z9hG4bKc0686d35e5c061602420679c72a2a9c1
Max-Forwards: 20
x-nt-corr-id: 1078a51bf4a670b693ff520178185ba7807c4ba5@
k: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec
l: 0

By: Chandi Bernier (chandi) 2005-11-14 14:14:29.000-0600

I'm actually trying to find info on the meaning of the packet.

It happens during an active SIP call but it seems to be sent every 6 to 10 minutes.

I understand that we cannont reply 200 OK if we don't understand it. I've only patched my code to send back 200 OK and it's been able to make 2hours call instead of 9 minutes.

I'll keep you informed of what I find about that packet.


By: Kevin P. Fleming (kpfleming) 2005-11-15 14:14:45.000-0600

I'm reclassifying this bug, as Asterisk cannot be expected to respond correctly to something that is outside the RFC (or appears to be so).

By: Olle Johansson (oej) 2005-12-01 17:49:33.000-0600

When you get documentation, please re-open this report. Thanks. /Olle

By: Olle Johansson (oej) 2006-09-21 07:56:48

Reopened after discussion with "hwt" on IRC.

By: hwt (hwt) 2006-09-22 06:24:23

This SIP INFO message is Nortel proprietary "ping" message that the MCS5xxx uses to check whether or not a call is still active. This message is sent periodically every 5-10 minutes. There is currently no way to disable this "feature" in the MCSes, so the handling of this message must be implemented on the client side.

By default, Asterisk will reply to this INFO message with a 403 Unauthorized, because the session is not authenticated. This is correct behavior and is in accordance with the RFC. However, for interoperability, I had to patch Asterisk in order complete calls longer than 5-10 minutes.

I have written a preliminary patch (for 1.2.10, but should be possible to apply to the whole 1.2-branch) that will look for the "k" header in all SIP INFO messages that arrives, and if it matches a string "com.nortelnetworks.firewall,p-3rdpartycontrol,nosec" Asterisk wil reply with a 200 OK (which is all the MCS requires).

This is a very naughty packet: Unless a 200 OK is sent back to the MCS as it expects, the MCS will simply terminate the session, without notifying Asterisk.

By: jmls (jmls) 2006-11-01 12:56:09.000-0600

chandi: did you apply and test this patch ?

By: Joshua C. Colp (jcolp) 2006-11-16 17:32:24.000-0600

What do you think about this? I'm very hesitant on putting something like this in as I believe the Nortel should have an option to turn it off.

By: Scott Walde (srw) 2006-12-06 20:54:23.000-0600

Could the author of this patch please put it in some context for us non-1.2.10 people?  (It doesn't appear to fit at lines 8792ff in 1.2.13)  thanks.

By: Olle Johansson (oej) 2006-12-07 02:05:39.000-0600

This patch is clearly wrong and won't be accepted. There was a reason I wanted to keep this open - yes, it seems that the retransmits is handled in a very bad way that we need to fix.

By: netonfire (netonfire) 2007-01-03 18:55:47.000-0600

Extract from RFC2976
2.2 Responses to the INFO Request Method
If a server receives an INFO request it MUST send a final
A 200 OK response MUST be sent by a UAS for an INFO request with
no message body if the INFO request was successfully received for
an existing call. Beyond that, no additional operations are

So, if the content-length is 0, as in this case, shouldn't Asterisk return a 200 OK response?

By: jmls (jmls) 2007-05-28 02:24:03

oej, do you still want to keep this open ?

By: Sergio Diaz (oslec) 2007-08-22 23:36:31

Hi People,
My Provider have an Nortel MCS 5200 sip proxy, and yes the call dropped after 6-11 minutes.

I apply the patch by HWT in Asterisk Version SVN-branch-1.2-r69258M in the chan_sip.c => Module (static void handle_request_info(struct sip_pvt *p, struct sip_request *req)

I take off the code for Snom and put the patch for Nortel . Sorry i dont use Snom.

Im able to make calls to more of 11 Minutes. Then when the asterisk receive the Info Packet for Nortel, asterisk response with a 200 OK.

Now, the system its fine.

Question, this patch apply to all 1.2 Head and 1.4 Head ?


The Packet Info by Nortel MCS
INFO sip:5530289500@ SIP/2.0.

t: "Costumer "

f: <sip:3000445554083549@>;tag=4455084331571741576.

i: 418e1f8b319d61f94650258337158ba6@

CSeq: 81724 INFO.

v: SIP/2.0/UDP;branch=z9hG4bK9bb4ffae274492b5baa1aecfb6c316bc.

Max-Forwards: 20.

x-nt-corr-id: 1148122ec991a52386781ea32d5637d1cc98e89260@

k: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec.

l: 0.

The Answer of Asterisk
U ->

SIP/2.0 403 Unauthorized.

Via: SIP/2.0/UDP;branch=z9hG4bK9bb4ffae274492b5baa1aecfb6c316bc;received=

From: <sip:3000445554083549@>;tag=4455084331571741576.

To: "Bill Bus Activos Publicitarios" <sip:5530289500@>;tag=as39d30f5f.

Call-ID: 418e1f8b319d61f94650258337158ba6@

CSeq: 81724 INFO.

User-Agent: rm-ip-pbx.


Content-Length: 0.

X-Asterisk-HangupCause: Normal Clearing.


By: netonfire (netonfire) 2007-09-01 08:37:02

Hi All,

I made some suggestion on the www.voip-info.com forum. (see link below)

My solution is to check the content length of the INFO packet near the end of the handle_request_info() function. As according to RFC2976, if there is no message body, we should just return "200 OK".

This solution has been working fine for me, and for many people using HKBN 2B service which uses Nortel MCS 5200.

I don't know how to summit the code into Asterisk SVN, maybe someone can help and make it into the next release.


By: Igor Goncharovsky (igorg) 2007-09-03 00:48:49

Ok, there is patch based on netonfire suggestion.

By: Digium Subversion (svnbot) 2007-11-02 15:18:34

Repository: asterisk
Revision: 88328

U   branches/1.4/channels/chan_sip.c

r88328 | file | 2007-11-02 15:18:33 -0500 (Fri, 02 Nov 2007) | 6 lines

If an INFO request within a dialog is received with a content length of 0 simply send back a 200 OK. It is valid to do this and the remote side is probably using it to make sure the signalling is still alive.
(closes issue ASTERISK-5599)
Reported by: chandi
     infofix-81430-1.patch uploaded by IgorG (license 20)


By: Digium Subversion (svnbot) 2007-11-02 15:20:53

Repository: asterisk
Revision: 88329

_U  trunk/
U   trunk/channels/chan_sip.c

r88329 | file | 2007-11-02 15:20:53 -0500 (Fri, 02 Nov 2007) | 14 lines

Merged revisions 88328 via svnmerge from

r88328 | file | 2007-11-02 17:20:21 -0300 (Fri, 02 Nov 2007) | 6 lines

If an INFO request within a dialog is received with a content length of 0 simply send back a 200 OK. It is valid to do this and the remote side is probably using it to make sure the signalling is still alive.
(closes issue ASTERISK-5599)
Reported by: chandi
     infofix-81430-1.patch uploaded by IgorG (license 20)