Solved: Hi,I´m currently having the

Matt Smith · ‎06-05-2013

Our German office has a 2901 CUBE which handles all the local SIP trunks. The CUBE is connected to CUCM BE in our HQ via SIP.

The local provider we have been using to-date with Asterisk doesn't pass the DID along in a call, instead they assign us user/passwords for each DID which I have each registered as a trunk (ie 4 DIDS = 4 accounts).

Each trunk has a dial-peer associated with the account number (destination-pattern) which has a session target of CUCM. Auth is in each dial-peer as well, so inbound calls have no issues.

On an outbound call I've had to use sip-profiles to modify the from header to show a proper CLID.

My issue arises about 15.5 minutes into an outbound call, when it appears CUCM sends a re-invite which doesn't get authenticated correctly. The ITSP returns a 403 message as the call is dropped, which seems to indicate I'm authing with the wrong user/password. This is entirely likely, as I can't figure out how to create dial-peers for outbound calls which first look at the account number (ie callers DID or something similar), so I'm sending all our outbound calls via one trunk and rewriting the header to include the correct CLID.

I'm just finishing up in the German office tonight but can't solve this issue, any help is greatly appreciated.

1. Is there a way to use a users DID (in my case account number) on outbound calls in a dial-peer?

2. Can I re-write the sip header, referencing the current account instead of the outbound dial-peer's authentication info?

3. I'm asking the ITSP if they can switch to IP authentication instead but I have little hope.

Here is the 403 error:

*Jun  5 12:46:21.180: //5726/A75EB7B6A5F8/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:0015195132407@85.88.5.233 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.6:5060;branch=z9hG4bK2AED268E
From: <sip:8686170389@sip.dcalling.de>;tag=312D814-D41
To: "0015195132407" <sip:0015195132407@85.88.5.233>;tag=as461b21b1
Date: Wed, 05 Jun 2013 12:46:21 GMT
Call-ID: 070c1d6a4ed8391e6ca1febd4b350def@85.88.5.233Route: <sip:85.88.5.252;lr;ftag=as461b21b1;did=743.1f07c223>
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2808002486-3440513506-2784554948-2737663134
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M2
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 INVITE
Max-Forwards: 70
Timestamp: 1370436381
Contact: <sip:8686170389@10.1.1.6:5060>
Expires: 180
Allow-Events: telephone-event
Proxy-Authorization: Digest username="8686170390",realm="sip.dcalling.de",uri="sip:0015195132407@85.88.5.233",response="1a91028846d6881b901ccdcb8486dcca",nonce="51af33c100013a017cf9369b8055ac613bb0c4dda2d5a66d",algorithm=md5
Session-Expires:  1800;refresher=uac
Content-Type: application/sdp
Content-Length: 235

v=0
o=CiscoSystemsSIP-GW-UserAgent 9747 7945 IN IP4 10.1.1.6
s=SIP Call
c=IN IP4 10.1.1.6
t=0 0
m=audio 17664 RTP/AVP 0 101
c=IN IP4 10.1.1.6
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

*Jun  5 12:46:21.188: //5726/A75EB7B6A5F8/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 403 Use From=IDVia: SIP/2.0/UDP 10.1.1.6:5060;received=87.79.33.14;rport=6494;branch=z9hG4bK2AED268E
From: <sip:8686170389@sip.dcalling.de>;tag=312D814-D41
To: "0015195132407" <sip:0015195132407@85.88.5.233>;tag=as461b21b1
Call-ID: 070c1d6a4ed8391e6ca1febd4b350def@85.88.5.233CSeq: 102 INVITE
Server: DALASON GmbH SIP Proxy
Content-Length: 0

Jagpreet Singh · ‎06-08-2013

Hi Steve,

I am no CUBE expert, but can you try to put in the configuration to modify REINVITES as well. Example:

request REINVITE sip-header From modify "452@10.1.1.6" "8686170390@sip.dcalling.de"

I am unsure if that will work as I havnt tested that in my lab, but its worth a shot, although I would think that the INVITE modification shouldve worked. Also can you please share the TAC case number?

Regards,

Jagpreet

View solution in original post

Matt Smith · ‎06-07-2013

Some additional info:

I'm rewriting INVITE's so I can authenticate with our provider based on individual accounts per DID, but when CUCM sends a re-INVITE after about 15 minutes the CUBE forwards it without re-writing the headers.

An example from my config:

request INVITE sip-header From modify "452@10.1.1.6" "8686170390@sip.dcalling.de"

request INVITE sip-header From modify "Hotelling Station 2" "004922145580009"

And the SIP Messages showing the headers aren't being rewritten:

After we receive an invite from CUCM , CUBE sends invite to provider

041685: *Jun 6 23:44:11.640: //5424/3371E0800000/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:0015195132407@85.88.5.233 SIP/2.0

Via: SIP/2.0/UDP 10.1.1.6:5060;branch=z9hG4bK2A8F880

From: "Hotelling Station 2" <sip:452@10.1.1.6>;tag=2DAFB1C-1137

To: <sip:0015195132407@sip.dcalling.de>;tag=as0432f49d

Date: Thu, 06 Jun 2013 23:44:11 GMT

Call-ID: B994F5E1-CE3711E2-9856ABC2-81604F43@10.1.1.6

Route: <85.88.5.252>

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 0863101056-0000065536-0000004665-0503709706

User-Agent: Cisco-SIPGateway/IOS-15.2.4.M2

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 103 INVITE

Max-Forwards: 70

Timestamp: 1370562251

Contact: <sip:452@10.1.1.6:5060>

Expires: 180

Allow-Events: telephone-event

Proxy-Authorization: Digest username="8686170390",realm="sip.dcalling.de",uri="sip:0015195132407@85.88.5.233",response="snip",nonce="snip",algorithm=md5

Content-Type: application/sdp

Content-Length: 235

v=0

o=CiscoSystemsSIP-GW-UserAgent 4491 8581 IN IP4 10.1.1.6

s=SIP Call

c=IN IP4 10.1.1.6

t=0 0

m=audio 16650 RTP/AVP 0 101

c=IN IP4 10.1.1.6

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

Provider sends below

041687: *Jun 6 23:44:11.648: //5424/3371E0800000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 407 Proxy Authentication Required

Via: SIP/2.0/UDP 10.1.1.6:5060;received=87.79.33.14;rport=61535;branch=z9hG4bK2A8F880

From: "Hotelling Station 2" <sip:452@10.1.1.6>;tag=2DAFB1C-1137

To: <sip:0015195132407@sip.dcalling.de>;tag=as0432f49d

Call-ID: B994F5E1-CE3711E2-9856ABC2-81604F43@10.1.1.6

CSeq: 103 INVITE

Proxy-Authenticate: Digest realm="10.1.1.6", nonce="snip"

Server: DALASON GmbH SIP Proxy

Content-Length: 0

CUBE attempts again

041689: *Jun 6 23:44:11.652: //5424/3371E0800000/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:0015195132407@85.88.5.233 SIP/2.0

Via: SIP/2.0/UDP 10.1.1.6:5060;branch=z9hG4bK2A901522

From: "Hotelling Station 2" <sip:452@10.1.1.6>;tag=2DAFB1C-1137

To: <sip:0015195132407@sip.dcalling.de>;tag=as0432f49d

Date: Thu, 06 Jun 2013 23:44:11 GMT

Call-ID: B994F5E1-CE3711E2-9856ABC2-81604F43@10.1.1.6

Route: <85.88.5.252>

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 0863101056-0000065536-0000004665-0503709706

User-Agent: Cisco-SIPGateway/IOS-15.2.4.M2

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 104 INVITE

Max-Forwards: 70

Timestamp: 1370562251

Contact: <sip:452@10.1.1.6:5060>

Expires: 180

Allow-Events: telephone-event

Proxy-Authorization: Digest username="8686170390",realm="sip.dcalling.de",uri="sip:0015195132407@85.88.5.233",response="snip",nonce="snip",algorithm=md5

Proxy-Authorization: Digest username="8686170390",realm="10.1.1.6",uri="sip:0015195132407@85.88.5.233",response="snip",nonce="snip",algorithm=md5

Content-Type: application/sdp

Content-Length: 235

v=0

o=CiscoSystemsSIP-GW-UserAgent 4491 8581 IN IP4 10.1.1.6

s=SIP Call

c=IN IP4 10.1.1.6

t=0 0

m=audio 16650 RTP/AVP 0 101

c=IN IP4 10.1.1.6

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

Provider sends not authorized

041690: *Jun 6 23:44:11.660: //5424/3371E0800000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 407 Proxy Authentication Required

Via: SIP/2.0/UDP 10.1.1.6:5060;received=87.79.33.14;rport=61535;branch=z9hG4bK2A901522

From: "Hotelling Station 2" <sip:452@10.1.1.6>;tag=2DAFB1C-1137

To: <sip:0015195132407@sip.dcalling.de>;tag=as0432f49d

Call-ID: B994F5E1-CE3711E2-9856ABC2-81604F43@10.1.1.6

CSeq: 104 INVITE

Proxy-Authenticate: Digest realm="10.1.1.6", nonce="snip"

Server: DALASON GmbH SIP Proxy

Content-Length: 0

CUCM sends bye after 30 seconds into the Invite

041705: *Jun 6 23:44:43.792: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

BYE sip:0015195132407@10.1.1.6:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.0.6.30:5060;branch=z9hG4bK3bce260426de

From: "Hotelling Station 2" <sip:452@10.0.6.30>;tag=14168~d732e07f-799a-4d2b-9d6a-ae2aaf54507d-25456007

To: <sip:0015195132407@10.1.1.6>;tag=2DAFC7C-1E8A

Date: Thu, 06 Jun 2013 23:46:26 GMT

Call-ID: 3371e080-1b111bce-15a2-1e06000a@10.0.6.30

User-Agent: Cisco-CUCM9.1

Max-Forwards: 70

P-Asserted-Identity: "Hotelling Station 2" <sip:452@10.0.6.30>

CSeq: 103 BYE

Reason: Q.850;cause=86

Content-Length: 0

I have TAC assisting as well, but Id like to get this done on the weekend before the branch office is in.

Also some pertenant info: I'm running the branch in SRST, where our calls do NOT drop, as CUCM isn't around to send that re-INVITE. This is a last ditch effort as we've sacrificed intra-office calling for external calling reliablity.

Any help is greately appreciated.

Steve

Jagpreet Singh · ‎06-08-2013

Hi Steve,

I am no CUBE expert, but can you try to put in the configuration to modify REINVITES as well. Example:

request REINVITE sip-header From modify "452@10.1.1.6" "8686170390@sip.dcalling.de"

I am unsure if that will work as I havnt tested that in my lab, but its worth a shot, although I would think that the INVITE modification shouldve worked. Also can you please share the TAC case number?

Regards,

Jagpreet

Matt Smith · ‎06-08-2013

Thanks Jagpreet,

Amazingly enough I was actually putting that rewrite in when you posted... and currently I'm on minute 22 of a test call!

Amazing.

Why debug shows it as INVITE when the rewrite rules have a REINVITE option, I do not know. Very confusing.

Appreciate your response,

TAC case is 626207917

Ayodeji Okanlawon · ‎06-08-2013

Steve,

There is no method in SIP called a REINVITE....So you will never see that anywhere in a SIP trace. I am even surprised it is present in the sip profile rules..The only way you identiy a RE-INVITE is via the "to" tag...

Any original invite doesnt have a "To" tag, a subsequent RE-INVITE will have a "To" Tag

Something like this: whenever you see a To tag, thats a RE-INVITE

To: <09825433593>;tag=1324169367-1360768922728-

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

inaiate87 · ‎08-21-2014

Hi,

I´m currently having the same issue.

Can you tell me what changes you made on the configuration?

Kind Regards!!!

SIP trunks on CUBE require user auth - call dropped on re-invite