SIP in IOS 12.4(22)T

Unanswered Question


i upgrade the 2811 router with the latest IOS... but my SIP trunk connection does not work anymore... as soon as the call is picked up the call drops and i have the following errors...

019876: Feb 17 13:48:39.631 EST: %SYS-5-CONFIG_I: Configured from console by adm

in on vty0 (

019877: Feb 17 13:49:03.232 EST: //1621/775F16D78F94/SIP/Error/sipSPI_ipip_set_h

istory_info_header: Not SIP2SIP mode

019878: Feb 17 13:49:03.700 EST: //1621/775F16D78F94/SIP/Error/sipSPI_ipip_set_h

istory_info_header: Not SIP2SIP mode

SIP: (1621) Group (a= group line) attribute, level 65535 instance 1 not found.

SIP: Attribute mid, level 1 instance 1 not found.

019879: Feb 17 13:49:16.676 EST: //1621/775F16D78F94/SIP/Error/sipSPIProcessNoti

fyCallInfoHeader: Call-Info header with for Unsolicited Notify Absent,Disabling

Unsolicited Notifies

SIP: Attribute mid, level 1 instance 1 not found.

019880: Feb 17 13:49:16.688 EST: //-1/xxxxxxxxxxxx/SIP/Error/ccsip_process_udp_q

ueue_event: UDP: Mismatch in send msg's target addr:, port: 5060 to

those in entry's values

019881: Feb 17 13:49:16.688 EST: //-1/xxxxxxxxxxxx/SIP/Error/ccsip_process_udp_q

ueue_event: addr:, port: 5060

019882: Feb 17 13:49:16.696 EST: //-1/xxxxxxxxxxxx/SIP/Error/act_active_send_msg

_failure: Send Error to for transport UDP

019883: Feb 17 13:49:16.696 EST: //-1/xxxxxxxxxxxx/SIP/Error/sipSPIGetContentQSI

G: No Inbound Container Created !!!

019884: Feb 17 13:49:16.696 EST: //-1/xxxxxxxxxxxx/SIP/Error/sipSPIGetContentQ93

1: No Inbound Container Created !!!

019885: Feb 17 13:49:17.672 EST: //-1/xxxxxxxxxxxx/SIP/Error/sipSPILocateInviteD

ialogCCB: Could not find ccb for response

019886: Feb 17 13:49:18.672 EST: //-1/xxxxxxxxxxxx/SIP/Error/sipSPILocateInviteD

ialogCCB: Could not find ccb for response

019887: Feb 17 13:49:20.676 EST: //-1/xxxxxxxxxxxx/SIP/Error/sipSPILocateInviteD

ialogCCB: Could not find ccb for response

019888: Feb 17 13:54:45.158 EST: //-1/xxxxxxxxxxxx/SIP/Error/ccsip_process_udp_q

ueue_event: UDP: Mismatch in close conn msg's target addr:, port: 50

60 to those in entry's values

I modified the ip values for security....

Thank you


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Nicholas Matthews Tue, 02/17/2009 - 18:58

Hi Marian,

You're going to have to add more debugs than this. Those debugs don't have much meaning without the context of the SIP message that they correspond to. Even then, this looks like it could be an error in the conversation, and not just a single message.

What do we send? What do they send? Too many questions.


Paolo Bevilacqua Wed, 02/18/2009 - 08:29

Certainly a lot of questions may be asked but the simple fact is that it was working before and doesn't after an update.

In this case pretty much the only thing is to go back and if possible work with the TAC for the root cause to be found.

Nicholas Matthews Wed, 02/18/2009 - 13:05

Hi Marian,

I don't seen anything glaringly obvious in the debugs. It looks like we become unresponsive because of something probably in the 183 Session Progress, and based on the earlier debugs, something in the SDP.

Can you post the debugs of ccsip all for a call?


Hi All again,

yes i know it's very easy to go back.... but is intriguing.... you know.... and maybe we all learn something... :) plus the client is very cool and they are OK to play with the system for couple of days.... this trunk is used for long distance saveings.... and if for the next couple of days they'll pay couple of dollars more is no such a big deal.... plus my next step is to use iLBC codec... and for that i need this version.... :)

the attachment has the debug ccsip all...

I hope, Nick, that something will jump in your eye.... :)

Thanks again,


Nicholas Matthews Thu, 02/19/2009 - 19:51

Hi Marian,

It looks like there may be a problem with IOS believing there is a conflicting IP address contact field. This is probably related to the fact that we're doing an outbound lookup on DNS, and we're choosing the first value, or in this example. When the provider sending back their response, they tell us to send to and we reject it because it's not the address we know we're working with.

It's very possible that we tightened up the code to prevent talking to non-involved third parties and that a multiple-address DNS case wasn't taken into consideration.

You can open a TAC case for this to have someone take a deeper look. If you put my name in the request if may get routed to me via another engineer.

If you want to test this theory, you can refer to the SIP provider by IP address and it looks like it will work.


Hi Nick,

Yes i saw that... i tried to put the session target as ipv4 and is working... another thing that i did i wanted to compare the sip messages with the previous version and yes the IOS is accepting the other ip address.... intresting.... i uploaded the new IOS back and left it with the ipv4 in place... I'll see if there are call quality loss.... I'll open a TAC next week and I'll put your name in it.... i have a favor to ask.... by any chance do you have a document for sip configuration in V7.0? with the new features? all that i could find references 4.3....



Paolo Bevilacqua Thu, 02/19/2009 - 00:58

Nice attitude. I'll leave this to Nick, he has the touch, and the power to file a bug if necessary.

Good luck!


This Discussion