SIP Invite Question

Unanswered Question
Apr 24th, 2007

We are trying to get a SIP trunk established between a cisco 2811 and a provider using a Carrius AppTrigger Compleat 200...I am not familiar with providers equipment but here is the issues thus far:

Call from carrier completes to sip gateway.

Call from gateway doesn't complete and gateway recieves a 403 Forbidden message.

Teleco provider says the problem is in the cisco invite message..the source port is not 5060..some random number...I didn't think this would be an issue but when I trace a call coming into the gateway their device is sourcing on port 5060..when a trace of a call going to the provider is looked @ the source port is not 5060...

The teleco's equipment understands that this is a sip call but doesn't allow it..

See attachment for traces of telco and cisco equipment:

So is it possible to change the source port on the sip invite to be 5060 or is this not the underlying issue...any help would be appreciated...



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Paolo Bevilacqua Tue, 04/24/2007 - 14:21

Hi Joe, nice traces.

I'm not sure that the problem is because source port is different than 5060. Consider that the RFC explicitly allow the source port in messages, to be different than 5060.

What I think the problem could be, is that your 2811 is behind NAT, and this NAT is not properly changing the inside address of to whatever public address is using on the outside. So the ITSP sees an unknown address coming in, and rejects the call. It explicitly complains about: reject the INVITE from unprovisioned SIP element

I'm a bit perplexed because I see the ITSP address a private also, perhaps you can expalin the reason ?

Can you verify that your NAT device does support SIP? A cisco device would.

Alternatively, can you configure one interface of the 2811 to use a public address ? With the proper access-list you would be safe anyway.

joeharb Tue, 04/24/2007 - 14:35

Thanks for the reply...The teleco is actually a subsidiary of our company and there is no nating involved that I know of...I do wonder sip element on the telco side ( is expecting another address as its peer..say a public address...I do know that all the gear on our end (routers and switches) are cisco...

Hope I have made this clearer..



Paolo Bevilacqua Tue, 04/24/2007 - 14:44

Correct, in fact looking at the traces (again, pretty clear traces) it shows that there is no NAT.

Now, I'm a bit puzzled by the fact this callmanager is so strict about the source port in messages, and don't know of a way to restrict/change it.

Since the callmanager complains about "unprovisioned", can you ask to check again if your IP address has been entered correctly ?

Alternatively, could they not use your IP address at all, and ask for digest authentication ? The router would be able to support that using "authentication username ..." under "sip-ua".

joeharb Tue, 04/24/2007 - 14:51

I have thought about the other methods of authentication..haven't had a change to test that with the telco admins....btw..I want to make sure we understand the this is not a cisco callmangager...that is the name of the application that is running the sip service..

Question though on that..would my invite sitll come in on a radom source port?...if this is truly the issue I don't know if another method of authentication would help...

any thoughts..again thanks for you help...


Paolo Bevilacqua Tue, 04/24/2007 - 15:19

Hi Joe and thanks for the nice rating.

Yes it's clear your are using a third party device called callmanager.

I've been browsing the web a bit more and I can quite categorically tell you that the server must accept whatever source port is used for messages. Not only that, but the RFC3581 specifies that in case the new parameter "rport" is used, server must respond back to the source port used in the original messages. We are however digressing because that is not your case.

I hope you can find the solution in a trivial configuration mistake on the callmanager, or a change of authentication scheme. Else I suggest they contact the vendor and ask why the restriction on source ports. Consider for example that a popular SIP client like X-lite by default uses ephemeral ports both in the messages address, and in the Contact header.

So I think the callmanager must be prepared to deal with that.

ngss Wed, 04/25/2007 - 01:04

Hi Joe,

This is what I see from the trace.

Cisco 2811 ( send an INVITE always using port 5060 to a SIP Server (

This can be seen at both at your Cisco 2811 and at the SIP Server trace.

The SIP INVITE Request message is always started with 'INVITE...'

The ...[]: is not part of the SIP Message.

Then the SIP Server response back to the Cisco 2811 with 403 Forbidden, for some reason.

What I would like clarify here is that the 403 responce is not related to the other-than port 5060 at all.

You need to check with your provider what are they expected from your 2811.



joeharb Wed, 04/25/2007 - 05:21

Thanks for the reply,

I agree that the []: is not part of the SIP Message...and that the provider understands that this is a SIP invite...but for some reason the server rejects the call...I haven't been able to get any more information from the provider..

They have contacted their vendor and the vender has stated that the non 5060 port is the cause of the issue....from what I understand it is a "security feature"...


Paolo Bevilacqua Wed, 04/25/2007 - 05:29

Sorry the hear that answer from the vendor... I can assure you that what they call a "security feature", beside violating RFC, will severely limit interoperability and the provider will have a lot of issues from customers.

ngss Wed, 04/25/2007 - 17:36

Hi Joe,

I believe the vendor wrongly interpreted the error message.

If you look at RFC 3261, there are many possibilities why the Apptriger response with 403 Forbidden

I am particularly interested in this error log:-

@[email protected]_CallMgrA@ SIPDeliver::SeizeIndication(): reject the INVITE from unprovisioned SIP element

You need to check with the vendor relates this error.




This Discussion