cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2400
Views
0
Helpful
8
Replies

Please help with the From field

SHeidemann
Level 3
Level 3

I'm trying to setup a generic service provider. I keep getting 404 not found. They've said that my from field should say our trunkgroup username there and not the phone number. I've gone into CLI, and tried the command SIP-UA username atos password XXX, it's the same though. Is there a way to change the from field so that I can get registered?

I've been at this all week, it's just a test deploy but I've got to get going please help!!!

Stephanie

2 Accepted Solutions

Accepted Solutions

Maulik Shah
Level 5
Level 5

You could try the below and see if this helps:

sip-ua

  credentials username password realm

and see if that helps. Would need the SIP logs to check what is being sent and what exactly the SP wants to see.

One other option is that with the new 8.0 early adopter software pack that will come out later this week - you can have a username in addition to a phone number using the same credentials CLI.

View solution in original post

There are a lot of calls in the log captured. Can you help explain a few things:

I see the SIP REGISTER message is using the name (at least for the SIP REGISTER message in the log):

002598: Dec  4 12:39:39.571: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:stl06a.netlogic.net:5060 SIP/2.0

Where do you see name not going out? Remember the credentials CLI is for registration not for outbound caller ID (From header). The Caller ID for outbound calls (From header) will have name (as the name of the user on the IP Phone) and number is the DID you use (either main number DID or extension DID) - see snip below:

003193: Dec  4 12:40:12.372: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:4767979@stl06a.netlogic.net:5060 SIP/2.0
Date: Fri, 04 Dec 2009 18:40:12 GMT
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
From: "SixtyFive SeventyNine" <4028173700>@stl06a.netlogic.net>;tag=45B4BA0-A00

which looks ok to me.

Stepping back - what is the problem you are seeing currently:

- Outbound calls fail?

- Inbound calls fail?

- Both way calls fail?

- The log was taken when credentials CLI was re entered? Or before or after?

View solution in original post

8 Replies 8

Maulik Shah
Level 5
Level 5

You could try the below and see if this helps:

sip-ua

  credentials username password realm

and see if that helps. Would need the SIP logs to check what is being sent and what exactly the SP wants to see.

One other option is that with the new 8.0 early adopter software pack that will come out later this week - you can have a username in addition to a phone number using the same credentials CLI.

Thanks for the help,

Actually I figured it out before I got the answer. I was going to reply with my own answer, but yours is correct.

I also saw that since I made that configuration change it added the username and password under credentials in the CCA. Trying to stay in line with Cisco's ideas of not using the CLI to have to make things work. I think this would have worked to configure it from there.

So I can make out going calls. Next thing is the incoming calls. They aren't working either, busy signal upon dialing. Any ideas on where I should begin troubleshooting this would be nice.

Thanks lots.

Stephanie

Would need logs for this - check tip below for gathering logs using CCA for SIP Trunk issues:

If calls are not being able to be placed to / from the UC500 to the SIP or the registration has failed, go to Troubleshoot > Telephony Diagnostics > Voice Debug Log. Select device, check VoIP (SIP) and click Apply Debug. Make the failed call or the event, save log file to Log File Directory and click on Generate Troubleshooting Log. Then click OK to disable debug logging.

Strange enough to ask for more assistance

Things were working pretty beautifully through the thanksgiving holiday. Things just kept working, but this week I keep running into the same problem. Over the weekend it was at least sending the correct info in the from field. The connection might drop off, so I would have to take the credentials out and put them back in, for whatever reason it wouldn't stay up, but once I did the from field was right. Now it keeps using the number and not the name that is configured. However when I remove and add the credentials it will work, but not for too long, and I never see the correct credentials going out in the debug.

If you have any advice I'll sure take it. Here is the debug log performed in CCA.

Thanks

Stephanie

There are a lot of calls in the log captured. Can you help explain a few things:

I see the SIP REGISTER message is using the name (at least for the SIP REGISTER message in the log):

002598: Dec  4 12:39:39.571: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:stl06a.netlogic.net:5060 SIP/2.0

Where do you see name not going out? Remember the credentials CLI is for registration not for outbound caller ID (From header). The Caller ID for outbound calls (From header) will have name (as the name of the user on the IP Phone) and number is the DID you use (either main number DID or extension DID) - see snip below:

003193: Dec  4 12:40:12.372: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:4767979@stl06a.netlogic.net:5060 SIP/2.0
Date: Fri, 04 Dec 2009 18:40:12 GMT
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
From: "SixtyFive SeventyNine" <4028173700>@stl06a.netlogic.net>;tag=45B4BA0-A00

which looks ok to me.

Stepping back - what is the problem you are seeing currently:

- Outbound calls fail?

- Inbound calls fail?

- Both way calls fail?

- The log was taken when credentials CLI was re entered? Or before or after?

Just thought I'd let you know, it just won't fail anymore. The debug I posted was created while it was failing, followed by me changing the credentials, fallowed by me showing the connection working after that. The failure had always been on inbound calls. My guess is that it was on my providers end, dropping the registered status, and by my taking out and adding in the credentials caused it to force a reregister? They must have fixed something on their end.

Thanks for your time on the issue

Stephanie

Wanted to let you know that the register was to be from name@stl06a.netlogic.net not 402817300@stl06a.netlogic.net

thanks

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: