cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Anonymous
Not applicable

SIP OPTIONS request gets answered by a 501 Not Implemented

Jump to solution

Hi,

I have been having some difficulty understanding why upon receiving SIP OPTIONS request my NetVanta 6310 answers with a "200 OK" and sometimes it answers with a "501 Not Implemented".  I would really like it to answers with "200 OK" and I guess someones already had this issue!

Here's the deal:

T01 is the trunk from the softswitch.  A Metaswitch CFS.

T02 is the trunk to the client's PBX.  A Mitel 3300 PBX.

As far as calling from/to either side, everything goes thru without any issue.

The part failing is where we use SIP OPTIONS to verify the availability of the trunk from the softswitch.  The PBX answers his OPTIONS request quite well.

When the PBX sends his SIP OPTIONS it gets answered "200 OK":

Rx: UDP src=192.168.1.2:5060 dst=192.168.1.1:5060

    OPTIONS sip:192.168.1.1:5060;transport=udp SIP/2.0

    Via: SIP/2.0/UDP labsog.somedomain.net:5060;branch=z9hG4bK1948758592-102926611

    Max-Forwards: 70

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

    Supported: replaces

    From: <sip:labsog.somedomain.net:5060>;tag=0_1948758592-102926612

    To: <sip:192.168.1.1:5060;transport=udp>

    Call-ID: 1948758592-102926610

    CSeq: 1 OPTIONS

    Contact: <sip:labsog.somedomain.net:5060;transport=udp>

    User-Agent: Mitel-3300-ICP 11.0.2.66

    Content-Length: 0

Tx: UDP src=192.168.1.1:5060 dst=192.168.1.2:5060

    SIP/2.0 200 OK

    From: <sip:labsog.somedomain.net:5060>;tag=0_1948758592-102926612

    To: <sip:192.168.1.1:5060>;tag=4d87230-7f000001-13c4-1ab4b2-63e1bbf-1ab4b2

    Call-ID: 1948758592-102926610

    CSeq: 1 OPTIONS

    Via: SIP/2.0/UDP labsog.somedomain.net:5060;received=192.168.1.2;branch=z9hG4bK1948758592-102926611

    Supported: 100rel,replaces

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

    User-Agent: ADTRAN_Netvanta_6310/A5.03.00.E

    Content-Length: 0

When the softswitch sends it's SIP OPTIONS it gets answered "501 Not Implemented":

Rx: UDP src=205.XXX.XXX.XXX:5060 dst=172.28.10.230:5060

    OPTIONS sip:metaswitch@172.28.10.230:5060;transport=udp SIP/2.0

    Via: SIP/2.0/UDP 205.XXX.XXX.XXX:5060;branch=z9hG4bK+ca17548f01433280d09cd2f163cc84791+sip+1+a6511224

    From: <sip:metaswitch@205.XXX.XXX.XXX:5060>;tag=205.XXX.XXX.XXX+1+1496460d+5a488fc9

    Content-Length: 0

    Supported: resource-priority, 100rel

    To: <sip:metaswitch@172.28.10.230>

    Contact: <sip:fa26977a002b9668986d84eda7e705d1@205.XXX.XXX.XXX:5060>

    Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event

    Max-Forwards: 69

    Call-ID: 0gQAAC8WAAACBAAALxYAAFOiyp/GRYq6B+rNtSlH+xHw7SXdCOf9lXGh8hoavbDd@205.XXX.XXX.XXX

    CSeq: 591356001 OPTIONS

    Organization: Metaswitch Networks

    Accept: application/sdp, application/dtmf-relay

    

Tx: UDP src=172.28.10.230:5060 dst=205.XXX.XXX.XXX:5060

    SIP/2.0 501 Not Implemented

    From: <sip:metaswitch@205.XXX.XXX.XXX:5060>;tag=205.XXX.XXX.XXX+1+1496460d+5a488fc9

    To: <sip:metaswitch@172.28.10.230>;tag=4d8bf88-7f000001-13c4-1ab942-2ae9c2b7-1ab942

    Call-ID: 0gQAAC8WAAACBAAALxYAAFOiyp/GRYq6B+rNtSlH+xHw7SXdCOf9lXGh8hoavbDd@205.XXX.XXX.XXX

    CSeq: 591356001 OPTIONS

    Via: SIP/2.0/UDP 205.XXX.XXX.XXX:5060;branch=z9hG4bK+ca17548f01433280d09cd2f163cc84791+sip+1+a6511224

    Content-Length: 0

The configuration(basic SIP trunk):

voice trunk T01 type sip

  description "Softswitch"

  sip-server primary 205.XXX.XXX.XXX

  trust-domain p-asserted-identity-required

  codec-group All

!

voice trunk T02 type sip

  description "3300ICP"

  sip-server primary 192.168.1.2

  trust-domain p-asserted-identity-required

  codec-group All

!

!

voice grouped-trunk SOFTSWITCH

  description "from softswitch"

  trunk T01

  accept $ cost 0

!

!

voice grouped-trunk MITEL

  description "to Mitel 3300"

  trunk T02

  accept $ cost 0

It looks to me as if some content of the header pushed by the softswitch could be causing this.. Maybe the user part "metaswitch@"?

Any hints/ideas are welcome!!

Thanks.

Labels (1)
0 Kudos
3 Solutions

Accepted Solutions
Anonymous
Not applicable

Re: SIP OPTIONS request gets answered by a 501 Not Implemented

Jump to solution

I see many endpoints that respond with a 501 or some other message.

Usually as long as it receives a response the Meta should know that it’s up.

Are you experiencing any issues?

View solution in original post

0 Kudos
Anonymous
Not applicable

Re: SIP OPTIONS request gets answered by a 501 Not Implemented

Jump to solution

Jeacha,

Thanks for posting!  The unit should respond with a 200 OK if the user portion of the SIP URI is blank, or configured on the unit.  In other words, it is the "metaswitch" user that causes the 501 response.  You could try configuring a "dummy" voice user and see if it responds with a 200 OK.

voice user 1000

  sip-identity metaswitch T01

Thanks!

David

View solution in original post

br_
New Contributor II

Re: SIP OPTIONS request gets answered by a 501 Not Implemented

Jump to solution

I know this has been answered but we did find another solution to this.

We are using TA5Ks feeding TA354E ONTs, RPOTS, and TA900 series (not off the TA5Ks).  We have both a VP2500 and an ATCA UMGs being fed by Perimeta SBCs (All Metaswitch gear).

Initially our configs looked like this:

voice trunk T01 type sip

  sip-server primary 10.10.10.5

  registrar primary 10.10.10.5

  domain "sip.<domain>.com"

  codec-group G711ONLY

  grammar to host domain

We had the 501 Not Implemented error.

When we changed the configs to this:

voice trunk T01 type sip

  sip-server primary sip.<domain>.com

  codec-group G711ONLY

With or without domain "sip.<domain>.com" and grammar to host domain, as they are no longer being translated to an IP.

Also remember to implement ip name-server 10.10.10.2 command when only using the DNS.

The lines would register.  We have a ticket open with MS to see why this is but this was our cause and fix for the 501 we were receiving on multiple devices.

A note on the IP vs DNS:  the DNS we used pointed to the same IP we were using (so it shouldn't have mattered).

View solution in original post

0 Kudos
6 Replies
Anonymous
Not applicable

Re: SIP OPTIONS request gets answered by a 501 Not Implemented

Jump to solution

I see many endpoints that respond with a 501 or some other message.

Usually as long as it receives a response the Meta should know that it’s up.

Are you experiencing any issues?

0 Kudos
Anonymous
Not applicable

Re: SIP OPTIONS request gets answered by a 501 Not Implemented

Jump to solution

Thanks unified for your answer.

You are right, I do not experience any issue with the 501 or this setup as a whole. 

I am just trying to figure this out since the NetVanta 6310 is answering 200OK to the PBX there is no reason why it could not answer 200OK to the softswitch.

It's the same endpoint, it has to be something in the OPTIONS message which AOS SIP Parser doesn't like/understand..

Anonymous
Not applicable

Re: SIP OPTIONS request gets answered by a 501 Not Implemented

Jump to solution

Jeacha,

Thanks for posting!  The unit should respond with a 200 OK if the user portion of the SIP URI is blank, or configured on the unit.  In other words, it is the "metaswitch" user that causes the 501 response.  You could try configuring a "dummy" voice user and see if it responds with a 200 OK.

voice user 1000

  sip-identity metaswitch T01

Thanks!

David

jayh
Honored Contributor
Honored Contributor

Re: SIP OPTIONS request gets answered by a 501 Not Implemented

Jump to solution

See http://www.ietf.org/rfc/rfc3261.txt specifically section 11.

11.2 Processing of OPTIONS Request

The response to an OPTIONS is constructed using the standard rules

  for a SIP response as discussed in Section 8.2.6. The response code

  chosen MUST be the same that would have been chosen had the request

  been an INVITE. That is, a 200 (OK) would be returned if the UAS is

  ready to accept a call, a 486 (Busy Here) would be returned if the

  UAS is busy, etc. This allows an OPTIONS request to be used to

  determine the basic state of a UAS, which can be an indication of

  whether the UAS will accept an INVITE request.

The OPTIONS from Meta contains:

Accept: application/sdp, application/dtmf-relay

If the Adtran doesn't handle dtmf-relay then it is properly responding that it is not implemented.  There also is no Allow: line in the OPTIONS request from the Meta which may be an issue.

OPTIONS is really a way to query a SIP endpoint, "If I want to do "X", can you do it?" without actually doing "X".  In this case the Meta is asking for something that isn't implemented or failing to ask for anything at all.

I wouldn't worry about it. 

Anonymous
Not applicable

Re: SIP OPTIONS request gets answered by a 501 Not Implemented

Jump to solution

Thanks David for your answer.

I tried your solution and it's working pretty well !

I will be working on removing the user part using mesage manipulation on the meta.

This is exactly the answer I was looking for!

br_
New Contributor II

Re: SIP OPTIONS request gets answered by a 501 Not Implemented

Jump to solution

I know this has been answered but we did find another solution to this.

We are using TA5Ks feeding TA354E ONTs, RPOTS, and TA900 series (not off the TA5Ks).  We have both a VP2500 and an ATCA UMGs being fed by Perimeta SBCs (All Metaswitch gear).

Initially our configs looked like this:

voice trunk T01 type sip

  sip-server primary 10.10.10.5

  registrar primary 10.10.10.5

  domain "sip.<domain>.com"

  codec-group G711ONLY

  grammar to host domain

We had the 501 Not Implemented error.

When we changed the configs to this:

voice trunk T01 type sip

  sip-server primary sip.<domain>.com

  codec-group G711ONLY

With or without domain "sip.<domain>.com" and grammar to host domain, as they are no longer being translated to an IP.

Also remember to implement ip name-server 10.10.10.2 command when only using the DNS.

The lines would register.  We have a ticket open with MS to see why this is but this was our cause and fix for the 501 we were receiving on multiple devices.

A note on the IP vs DNS:  the DNS we used pointed to the same IP we were using (so it shouldn't have mattered).

0 Kudos